ntldr - Java

Saturday, March 20, 2010

Java EE lesson from this week:

At least on WebSphere Application Server v6.1, ordering of elements matters in a .war file's web.xml definition file.

<servlet-mapping> definitions must occur after the servlet being mapped has been defined. So this works:

<servlet id="JAXWS_MyFirstService">
  <description>My first JAX-WS demo service</description>
  <display-name>JAX-WS: My First Service</display-name>
  <servlet-name>com.ntldr.example.jaxws.MyFirstServiceSoap12PortImpl</servlet-name>
  <servlet-class>com.ntldr.example.jaxws.MyFirstServiceSoap12PortImpl</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlate-mapping>
  <servlet-name>com.ntldr.example.jaxws.MyFirstServiceSoap12PortImpl</servlet-name>
  <url-pattern>/MyFirstService/Soap12</url-pattern>
</servlate-mapping>

(good!)

But this generates bizarre NullPointerException's during attempts to load the .ear file:

<servlate-mapping>
  <servlet-name>com.ntldr.example.jaxws.MyFirstServiceSoap12PortImpl</servlet-name>
  <url-pattern>/MyFirstService/Soap12</url-pattern>
</servlate-mapping>

...

<servlet id="JAXWS_MyFirstService">
  <description>My first JAX-WS demo service</description>
  <display-name>JAX-WS: My First Service</display-name>
  <servlet-name>com.ntldr.example.jaxws.MyFirstServiceSoap12PortImpl</servlet-name>
  <servlet-class>com.ntldr.example.jaxws.MyFirstServiceSoap12PortImpl</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>

(bad!)

Yes, I ran into this problem this week at work. And it took me forever to realize that I'd made such a stupid mistake. So, keep in mind: servlet-mapping comes after servlet!

Now playing: Emm Gryner – Stray Bullets – 05 Holiday

Saturday, March 20, 2010 22:48:42 UTC

Comments [0] -
Java

Tuesday, April 29, 2008

Maven with a UNC home directory

At work, we use Maven to do builds for the project I work on. The Infrastructure IT people also have helpfully configured it so that every user account has a home directory conveniently located on a file server. Since we use Windows (Windows 2000 to be precise...), that home directory is a UNC path of the form \\server\share\folder.

This, it turns out, is rather bad for Maven.

See, Maven has a settings.xml file that allows you to configure it. Things like the local repository location, proxy settings, remote repositories, etc. get configured in that file. So it's kind of important. Maven looks for that file at <home directory>/.m2/settings.xml. And there in lies the problem with having <home directory> be a UNC path: Maven or Java or something just breaks, and that file isn't found/read.

Now, apparently if you put the file in C:\server\share\folder\.m2, Maven will find it. Sometimes. I didn't see consistent behaviour when trying that approach, and ended up abandoning it last year. Part of the problem may have been that different Maven things (mvn, Eclipse plugin) handled the exceptional situation differently, so builds might work from inside Eclipse and then fail on the command line.

So I began looking for a different approach, and took a look at the root cause of the problem. Attempting to get the Infrastructure people to change their policies and affect thousands of accounts as doomed to a slow failure, forcing me to try and find a workaround that was specific to my computer.

And at last! The grand unveiling! It's really quite simple in principle: if the home directory path is causing a problem, lets just make Maven see a different path. Doing so isn't quite that simple though.

Here are the steps:

First, a user specific HOME variable is created, pointing to the location the home directory needs to be redirected to.
Then define a system wide JAVA_OPTS variable, with the value of "-Duser.home=%HOME%". This isn't strictly necessary to get Maven itself to run, but is useful for creating a consistent experience with Java applications and this home directory redirection scheme.
Now, the magic Maven command-fu: create another system wide variable, MAVEN_OPTS. Value is "-Duser.home=%HOME%". Yes, this is the same as the JAVA_OPTS value. But mvn reads MAVEN_OPTS instead of JAVA_OPTS.
A bit of Eclipse integration: edit the eclipse.ini file and add the "-Duser.home=%HOME%" (note that I think you have to expand the %HOME% to the actual value; I doubt Eclipse uses Windows command prompt style variable referencing syntax) string after the -vmargs option. Now Eclipse will use the redirected home directory during startup.
More Eclipse integration: plugin/feature support: Go to Window->Preferences->Java->Installed JREs and edit any entries so they contain the VM argument "-Duser.home=%HOME%" (again, have to expand that %HOME% yourself to what the value is).

Okay, that should be it for just Maven. In theory these steps could be applied to other Java apps that have problems with finding settings in home directories. I've been lucky enough not to run into any of those apps though.

Now playing: Basia Bulat – Oh, My Darling – 07 In The Night

Tuesday, April 29, 2008 04:38:38 UTC

Comments [0] -
Java