Jan's comments about nested JAR class loading hit close to home for me.
We have had a similar issue with app client support. To help support
persistence units in app clients - and also as a way to resolve some
other things - we had to alter the format of the generated app client
JAR file so that it contains nested JARs. The app client must have the
nested JARs in its class path, so the app client container must expand
the app client JAR into a temporary directory (which is marked for
delete-on-exit). The JARs in that resulting temp directory are no longer
nested so they can be added to a class loader's class path routinely.
A while ago I looked for ways of avoiding the expansion step to avoid
the performance penalty that the expansion imposes. Among a number of
Java SE forum threads were people noting that one could write a custom
class loader that knew how to work with nested JARs. But some of those
notes pointed out that performance in loading classes and resource from
the nested JARs would be quite bad. If I remember correctly, the index
of a regular JAR file can be read directly, but a nested JAR is
compressed and one poster claimed that the entire nested JAR would have
to be expanded to gain access to the index and whatever internal
addressing scheme is used in JARs to locate particular entries.
I never investigated these claims or details myself, so I cannot vouch
for the accuracy of this description. I'm just describing what I read.
And I say all this only to reinforce Jan's feeling that it may be quite
some time before we see any changes in Java SE along these lines. I
hope I'm wrong about that!
- Tim
Jan Luehe wrote:
>
>
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>