Jan Luehe wrote On 04/24/07 02:01 PM,:
> Hi Kedar,
>
> kedar wrote On 04/24/07 11:39 AM,:
>
>> Hi Jan,
>>
>>> The closest feature that GlassFish offers in this respect is the
>>> --libraries
>>> option of the "asadmin deploy" command, which allows you to specify
>>> a list of
>>> JAR files that will be made visible to the application being
>>> deployed. In your case,
>>> you would specify the JAR files of the parent webapp when deploying
>>> any of its
>>> "child" apps.
>>>
>> You mean one should specify the jar files from within web-app that's
>> deployed
>> onto server? What would be the syntax of deploy command line?
>
>
>
> I was thinking of referencing the parent webapp's JAR files as JAR URLs,
> like this:
>
> * jar:file*:/<path-to-parent-war>!/WEB-INF/lib/<name-of-jar>
>
> <path-to-parent-war> would be the path to the parent webapp prior to
> its deployment
> (so that you don't need to know any GlassFish internals about the
> location of the deployed
> bits).
>
> I haven't verified if "asadmin deploy --libraries xxx" supports the
> above syntax.
> If it doesn't, we should fix it.
I've filed this enhancement issue:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=2917
(Add support for nested JAR files to <sun-web-app><class-loader>'s
extra-class-path attribute and to "asadmin deploy --libraries")
More generally, one should be able to list full URLs as the value of
the extra-class-path attribute in sun-web.xml or the --libraries argument
to "asadmin deploy". For backwards compatibility, any values that don't
start with a URL protocol identifier will be treated as file paths.
Couple of observations:
- After fixing the web container's classloader configuration logic to
no longer treat
jar:file:x1.war!/x2.jar
as a file path, but as a URL, the WebappClassLoader, which is a
subclass of URLClassLoader, still fails to load any classes from the
nested x2.jar.
I found that this is a known J2SE issue, see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4735639
("URLClassLoader does not work with jar: URLs")
which has this comment in its evaluation section:
It seems that with the advent of ear, rar, and war files from J2EE
such
nested JAR files are not uncommon, and it would be useful to be able
to load resources from them without having to extract individual
archive
members first.
This bug was filed back in 2002, so I'm not very confident this will
get fixed any time soon. I'll ping the responsible engineer for an
estimate.
Support for nested JAR files in GlassFish has a dependency on this bug
getting fixed.
- The extra-class-path attribute of the class-loader element in
sun-web.xml, as well as the --libraries argument to "asadmin deploy",
expect a list of JAR files separated by File.pathSeparatorChar, which is
equal to ':' on UNIX and will conflict with a URL's protocol separator,
which therefore will need to be escaped.
Jan