Hi, Keith.
The tricky part about this is that the Which class accepts a class and then converts the class name into a resource name (dots in the class name become slashes, and a ".class" is appended). It then opens a connection to that resource name and then gets the URI to that resource.
The Which logic assumes that the URI will be file:... which is certainly typically the case when an app is launched from the command line using the "java" command. But Java Web Start actually goes to some effort to hide the actual location of cached JARs, primarily for security reasons I think. So in the Java Web Start runtime environment, the URI is of the form http:... mirroring the listing of the JAR in the JNLP document.
There are places within the server-side logic of GlassFish that use file and directory navigation to find things of interest -- assuming that the logic is running in a "usual" java command environment. Such assumptions don't hold in the Java Web Start environment. I do not know for sure, but I suspect that there are potentially quite a few places in the server-side logic that make this assumption.
In my work on the ACC I made could avoid such dependencies because I knew the Java Web Start environment is different in this way (and others!). It's a different story with embedded server-side GlassFish.
- Tim
[Message sent by forum member 'tjquinn' (timothy.quinn_at_sun.com)]
http://forums.java.net/jive/thread.jspa?messageID=385057