Skip to main content

Custom Web-app Loader - How To?

33 replies [Last post]
jess_holle
Offline
Joined: 2003-06-11

I have a web app which needs to have its docroot visible to the web app classloader immediately before WEB-INF/classes and WEB-INF/lib/*.jar.

In Tomcat I do this easily enough by doing some trivial subclass extension of the web app loading classes and calling out my extended classes as part of my web app deployment XML.

Is any similar approach possible for Glassfish?

I know about the extra-class-path bit in sun-web.xml -- that helps but it appends to the web app classpath rather than inserts, which is a critical difference in this case.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
amyroh
Offline
Joined: 2004-05-06

Great to hear the loader override works. :-)

Please feel free to file an RFE for automatic creation of webapp with context.xml.

jess_holle
Offline
Joined: 2003-06-11

> Please feel free to file an RFE for automatic creation of webapp with context.xml.

Will do.

jess_holle
Offline
Joined: 2003-06-11

P.S. It is good to see that context.xml is supported for other use cases as well, e.g. I have other web apps wherein I use context.xml to configure a database connection pool this way.

jess_holle
Offline
Joined: 2003-06-11

Just by way of verification, I tried my application with and without "libraries" set to point to my docroot directory -- but with extra-class-path set in sun-web.xml in both cases.

My web app registers an MBean which has an operation exposing the Java equivalent of "which", i.e. calls getClass().getClassLoader().getResources(String) for a given resource name and returns the result as a String[]. [This is really a handy troubleshooting operation to expose in an MBean if you have complex classpaths and loads of jars, etc.]

At any rate both with and without specifying "libraries", a class known to exist in both docroot and WEB-INF/lib/*.jar was found first in the jar and last in the docroot in both cases. Using "libraries" didn't have any "insertion" effect.

km
Offline
Joined: 2005-10-28

OK, this might be worthwhile as a work-around till we figure out why --libraries does not work.

I am willing to suggest a work-around if you are certain that
- the classes in docroot are not hiding the application server's implementation classes (e.g. anything
in com.sun.enterprise package and subpackages thereof) and
- it is OK to modify the class-loading of *all* the deployed applications,

then

you can consider modifying classpath-prefix of java-config element in domain.xml.

Add: ${com.sun.aas.installRoot}/docroot to classpath-prefix and restart/retry.

This is of course not a recommended thing, but something that can work-around the problems.

The --libraries that I pointed you to was supposed to solve the problem you are facing. I have
asked Sivakumar to respond to this thread. But till then, you can try the above work-around.

Regards,
Kedar

jess_holle
Offline
Joined: 2003-06-11

First off I'd rather not modify the classloading of all deployed applications -- I am trying to avoid that.

Secondly what would modifying classpath-prefix do? Would it put each web app's docroot at the front of *its* loader? If so, that's of interest in the interim. On the other hand, if this puts my web app's docroot in a higher classloader then this is a non-starter as the classes loaded from my docroot depend on classes in WEB-INF/lib/*.jar and thus these must all be in the same classloader -- and I don't want to have to change the config every time something else gets added to WEB-INF/lib.

km
Offline
Joined: 2005-10-28

> First off I'd rather not modify the classloading of
> all deployed applications -- I am trying to avoid
> that.
>
> Secondly what would modifying classpath-prefix do?
> Would it put each web app's docroot at the front of
> *its* loader? If so, that's of interest in the
> interim. On the other hand, if this puts my web
> app's docroot in a higher classloader then this is a
> non-starter as the classes loaded from my docroot
> depend on classes in WEB-INF/lib/*.jar and thus
> these must all be in the same classloader -- and I
> don't want to have to change the config every time
> something else gets added to WEB-INF/lib.

OK, then this hack is not for you.
classpath-prefix modifies the effective classloading of the entire server.

Sivakumar Thyagarajan

Hi

>> interim. On the other hand, if this puts my web
>> app's docroot in a higher classloader then this is a
>> non-starter as the classes loaded from my docroot
>> depend on classes in WEB-INF/lib/*.jar and thus
>> these must all be in the same classloader -- and I
>> don't want to have to change the config every time
>> something else gets added to WEB-INF/lib.

Yes, placing a jar in the classpath-prefix places it in a classloader way above
in the hierarchy [to be specific, it prefixed the "shared chain" classloader.

For more gory details, please refer
https://glassfish.dev.java.net/javaee5/docs/DG/beade.html#beadf] and yes, as you
have rightly pointed out, if the docroot jars have references to
WEB-INF/lib/*.jars this would not work.

So if I understand correctly, you want to place some jars in docroot [that
depends on some jars in WEB-INF/lib], placed before WEB-INF/lib and hence should
be placed in the same classloader. Why do you want to control the order of jars
in a particular classloader? Do you expect jars placed in docroot to "shadow"
jars in WEB-INF/lib [ie. having two versions of a library in docroot and
web-inf/lib and expecting the docroot version to win?]?

If my understanding of your usecase above is right, "libraries" [application
specific classloader] also would not help us, because the specified "libraries"
for a web-app, are loaded by a classloader above the web-app, and hence
"docroot" jars would not have access to "web-inf/lib" jars.

The hierarchy for libraries would be something like this:

[connector classloader] - (1)
|
[libraries specified for web app "foo"] - (2)
|
[web app classloader "foo"] - (3)

The docroot jars would be loaded in (2) and will not be able to resolve
references to web-inf/lib classes in (3).

For this specific usecase, I don't think the current classloading options would
help. You might want to consider subclassing Tomcat discussions you were having
in this thread with JeanFrancois as the only option for now.

Thanks
--Siva

glassfish@javadesktop.org wrote:
>> First off I'd rather not modify the classloading of
>> all deployed applications -- I am trying to avoid
>> that.
>>
>> Secondly what would modifying classpath-prefix do?
>> Would it put each web app's docroot at the front of
>> *its* loader? If so, that's of interest in the
>> interim. On the other hand, if this puts my web
>> app's docroot in a higher classloader then this is a
>> non-starter as the classes loaded from my docroot
>> depend on classes in WEB-INF/lib/*.jar and thus
>> these must all be in the same classloader -- and I
>> don't want to have to change the config every time
>> something else gets added to WEB-INF/lib.
>
> OK, then this hack is not for you.
> classpath-prefix modifies the effective classloading of the entire server.
> [Message sent by forum member 'km' (km)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242003
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

To clarify, no I don't care about jar load order, nor do I want to add jars in docroot to the classloader path.

I want to add the docroot directory itself to the web app classloader entries -- and to do so prior to the normal entries (WEB-INF/classes and WEB-INF/lib/*.jar).

Sivakumar Thyagarajan

Hi

glassfish@javadesktop.org wrote:
> To clarify, no I don't care about jar load order, nor do I want to add jars in docroot to the classloader path.
>
> I want to add the docroot directory itself to the web app classloader entries -- and to do so prior to the normal entries (WEB-INF/classes and WEB-INF/lib/*.jar).

I think the two statements above seems to contradict each other. I understand
that the libraries/classes in docroot cannot be placed in server classpath or in
a libraries classloader but "to do so prior" to webapp classloader entries
implies load order, right?

Why is this "load order" required?

You had also mentioned earlier that docroot needed to houses libraries for
applets and other clients and that you wanted to use the same libraries in the
webapp. Is this assumption correct? If yes, could duplicating the same jar in
docroot and WEB-INF/lib help?

Thanks for all the context you have provided so far.

Thanks
--Siva.

> [Message sent by forum member 'jess_holle' (jess_holle)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242098
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

I don't care about the load order of jars with respect to one another. I do need the docroot directory itself (not jars therein) in the load order prior to the WEB-INF stuff, though.

The load order is fortunately not required in most cases -- we get by with the docroot at the end of the load order to a fair degree. This breaks down when a resource appears both in a jar and in the docroot, however -- which is done in cases where the default resource appears in both locations, but the docroot one is intended to be updatable and to override that in the jars.

As far as client libraries, no, the same jars are not used in the web-app (except for some 3rd-party jar cases in which case we duplicate jars betweeen docroot lib and WEB-INF/lib). The client libraries are mostly built from resources in docroot based on HTTP access logs produced when applets are run. This yields client jars containing what clients use at runtime but failover to "loose" classes, etc, in docroot is still required for cases that are missed. The big issue is really that duplicating all the resources that a client might use from docroot into WEB-INF/classes is prohibitive -- the resources therein need to be shared between the tiers. We used to replace WEB-INF/classes with a symbolic link to the docroot, but this threw some servlet engines into an infinite traversal loop and didn't work on UNIX [yes, I know there are symlink like things on Windows now, but they're still not really first class things].

Sivakumar Thyagarajan

> This breaks down when a resource appears both in a jar and in the docroot,
> however -- which is done in cases where the default resource appears in both
> locations, but the docroot one is intended to be updatable and to override that
> in the jars.

I was precisely asking if this is the usecase you intended to solve. Thanks for
clarifying and great to know that context.xml works for you now.

Thanks
--Siva.

glassfish@javadesktop.org wrote:
> I don't care about the load order of jars with respect to one another. I do need the docroot directory itself (not jars therein) in the load order prior to the WEB-INF stuff, though.
>
> The load order is fortunately not required in most cases -- we get by with the docroot at the end of the load order to a fair degree. This breaks down when a resource appears both in a jar and in the docroot, however -- which is done in cases where the default resource appears in both locations, but the docroot one is intended to be updatable and to override that in the jars.
>
> As far as client libraries, no, the same jars are not used in the web-app (except for some 3rd-party jar cases in which case we duplicate jars betweeen docroot lib and WEB-INF/lib). The client libraries are mostly built from resources in docroot based on HTTP access logs produced when applets are run. This yields client jars containing what clients use at runtime but failover to "loose" classes, etc, in docroot is still required for cases that are missed. The big issue is really that duplicating all the resources that a client might use from docroot into WEB-INF/classes is prohibitive -- the resources therein need to be shared between the tiers. We used to replace WEB-INF/classes with a symbolic link to the docroot, but this threw some servlet engines into an infinite traversal loop and didn't work on UNIX [yes, I know there are symlink like things on Windows now, but they're still not really first class things].
> [Message sent by forum member 'jess_holle' (jess_holle)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242158
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Jeanfrancois Arcand

Hi Jess,

glassfish@javadesktop.org wrote:
> I did a little digging in the Glassfish source.
>
> Lo and behold it uses the same old classes from Tomcat that I subclass and extend, namely org.apache.catalina.loader.WebappClassLoader, org.apache.naming.resources.FileDirContext, and org.apache.catalina.loader.WebappLoader.
>
> Is there a simple way I can tell Glassfish to use my own subclasses of these classes for my web app [as there is for Tomcat]?
> [Message sent by forum member 'jess_holle' (jess_holle)]

I don't think this is doable as I've never ported the functionality from
Tomcat, and I suspect (I might be wrong, I need to investigate) we
forked before the feature was added. Let me take a look at it and I will
come back to see how difficult it will be enable it in GlassFish.

Thanks

-- Jeanfrancois

>
> http://forums.java.net/jive/thread.jspa?messageID=241959
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

When did you fork?

We've been doing this subclassing bit in Tomcat since 4.1.x days via various sub-elements, i.e. and . I'm not sure if this was possible in 4.0 or 3.x days -- we just set the classpath for the entire servlet engine back then (and, yes, we *could* revert to this today, but it would be a step backwards).

I realize this is somewhat of an odd requirement and could always patch Glassfish itself. It would be far better overall to be able to modify the behavior by extension on a per-web-app basis, though.

Jeanfrancois Arcand

glassfish@javadesktop.org wrote:
> When did you fork?

Grizzly was born on 5.0.13 :-)

>
> We've been doing this subclassing bit in Tomcat since 4.1.x days via various sub-elements, i.e. and . I'm not sure if this was possible in 4.0 or 3.x days -- we just set the classpath for the entire servlet engine back then (and, yes, we *could* revert to this today, but it would be a step backwards).

OK now I recall :-) The loader can be defined in context.xml (and
server.xml) right? GlassFish supports context.xml[1] but I'm not sure
the loader element is supported. Should not be complicated to implement
and can be quite useful.

Are you defining it under context.xml or server.xml?

>
> I realize this is somewhat of an odd requirement and could always patch Glassfish itself. It would be far better overall to be able to modify the behavior by extension on a per-web-app basis, though.

Right :-) Then context.xml is the way to go (for GlassFish). Do you mind
filling an RFE?

Thanks!

-- Jeanfrancois

> [Message sent by forum member 'jess_holle' (jess_holle)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242008
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

In Tomcat we're using context.xml to specify our overrides.

I was unaware that Glassfish supported something similar. Is there documentaiton on this? Currently I have web-module and application-ref elements in domain.xml, which strikes me as a step backwards in that it requires insertion into an existing file rather than placement of a separation file.

I'd be happy to file an RFE though I'd like a little info as to what is known to be there already so as to be specific about what needs to be added -- e.g. I didn't even know I could use context.xml's similar to Tomcats, where to place them (in Tomcat they just go in conf subdirectories), etc.

amyroh
Offline
Joined: 2004-05-06

Jess,

Can you try your context.xml as described in my blog [1]? I haven't tested context.xml specifically for Loader element and am interested in your result.

Thanks,
Amy

[1] http://weblogs.java.net/blog/amyroh/archive/2007/05/context_webapp_1.html

jess_holle
Offline
Joined: 2003-06-11

No RFE necessary for the loader override. This works like a charm.

I dropped the same context.xml I used in Tomcat 5 into docroot/META-INF (minus unnecessary cruft), dropped a jar containing my extensions into Glassfish's lib directory, removed my sun-web.xml file, and everything worked perfectly.

Thanks for the help.

This does bring up another RFE, though... It would be really nice to be able to drop the context.xml into a certain Glassfish directory and have Glassfish automatically notice this file and load the web app in question. Tomcat has long had this capability instead of requiring one to actually change server.xml. It would be nice to have the equivalent for Glassfish to add web apps by simply creating appropriate text files in the right locations without altering domain.xml. [The context.xml in such cases much specify the docBase attribute on the element, of course.]

Or does that feature also exist and I'm just ignorant of it?

jess_holle
Offline
Joined: 2003-06-11

I have another use case for deploying via context.xml:

I have a web app directory that I wish to load into the servlet engine multiple times with different context names/paths and parameters in context.xml. The META-INF approach does not work for this case (unless perhaps you select the option to deploy the directory, but generally I don't want to do that).

The reason behind this particular use case is a simple web app that is focused on a database instance. Exactly the same web app code, etc, can be used but each running app gets a different set of DBCP and JNDI parameters so as to target a different dataset.

Sivakumar Thyagarajan

>> Specifying an "extra-class-path" of "." in sun-web.xml adds the docroot to
>> the classloader -- but after WEB-INF/lib/*.jar rather than before
>> WEB-INF/classes.

I don't know if this helps, but Jan Luehe in a conversation confirmed this:

"So it looks like the feature is working, except that the extra-class-path is
appended rather than prepended. We don't have any option that would allow you to
specify whether the extra-class-path should be appended or prepended. It is
appended by default."

Thanks
--Siva.

glassfish@javadesktop.org wrote:
> Looking more at the information sent, I believe --libraries is equivalent to the Libraries option in the JMX and admin consoles. I tried setting that to my docroot -- both as a relative and absolute path. This didn't seem to add docroot to the classloader anywhere, much less prior to WEB-INF/classes.
>
> Specifying an "extra-class-path" of "." in sun-web.xml adds the docroot to the classloader -- but after WEB-INF/lib/*.jar rather than before WEB-INF/classes.
> [Message sent by forum member 'jess_holle' (jess_holle)]
>
> http://forums.java.net/jive/thread.jspa?messageID=241799
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

Yes, extra-class-path works perfectly [i]except[/i] that it appends rather than inserts.

This is somewhat unsurprising as Tomcat has the same "append" option, but no insert option -- hence my subclassing of their loaders. An "insert" option would be preferable in both cases.

Sivakumar Thyagarajan

> This is somewhat unsurprising as Tomcat has the same "append" option, but no
> insert option -- hence my subclassing of their loaders. An "insert" option
> would be preferable in both cases.

Yes, I understand, but I don't know if feature compat with Tomcat was assumed
and whether this is a new RFE or a defect. Jean-Francois, could you help us with
this?

Thanks
--Siva.

glassfish@javadesktop.org wrote:
> Yes, extra-class-path works perfectly [i]except[/i] that it appends rather than inserts.
>
> This is somewhat unsurprising as Tomcat has the same "append" option, but no insert option -- hence my subclassing of their loaders. An "insert" option would be preferable in both cases.
> [Message sent by forum member 'jess_holle' (jess_holle)]
>
> http://forums.java.net/jive/thread.jspa?messageID=242099
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

Looking more at the information sent, I believe --libraries is equivalent to the Libraries option in the JMX and admin consoles. I tried setting that to my docroot -- both as a relative and absolute path. This didn't seem to add docroot to the classloader anywhere, much less prior to WEB-INF/classes.

Specifying an "extra-class-path" of "." in sun-web.xml adds the docroot to the classloader -- but after WEB-INF/lib/*.jar rather than before WEB-INF/classes.

km
Offline
Joined: 2005-10-28

Please attach your "domain.xml".

I find it strange that it does not work.

- Kedar

jess_holle
Offline
Joined: 2003-06-11

The domain.xml snippet in question is:

to which I've had at various times libraries="D:/viewstore/jessh_static_x10_view/Windchill/codebase" or libraries="."

Again unless directories listed in libraries are added [i]before[/i] the usual classloader entries for the web app (i.e. WEB-INF/classes and WEB-INF/lib/*.jar), this is not of interest since a similar edit in sun-web.xml can append such entries to the classloader list. I'm just looking for an ability to [i]insert[/i].

Sivakumar Thyagarajan

Hi Jesse

I am responding to various sections of this entire post. Apologies if the
responses seems scattered, but I missed this long conversation because of being
in a different timezone :(.

> to which I've had at various times libraries="D:/viewstore/jessh_static_x10_view/Windchill/codebase" or libraries="."

Did you point libraries to the directory "Windchill/codebase" or specific jars
in the directory? The libraries attribute should point to a comma separated list
of jars
https://glassfish.dev.java.net/javaee5/docs/DG/beade.html#gatej

Placing a "." would not work, as the "." would be considered, as the current
working directory of the VM, which is, IIRC, ${install_root}/config. So this
would effectively be equivalent to not setting any libraries for the app.

> directories listed in libraries are added [i]before[/i] the usual classloader entries for the web app

Yes the specified "libraries" jars are loaded before the web app's classes in a
classloader placed above the web-app's classloader.

Thanks
--Siva.

glassfish@javadesktop.org wrote:
> The domain.xml snippet in question is:
>
>
>
> to which I've had at various times libraries="D:/viewstore/jessh_static_x10_view/Windchill/codebase" or libraries="."
>
> Again unless directories listed in libraries are added [i]before[/i] the usual classloader entries for the web app (i.e. WEB-INF/classes and WEB-INF/lib/*.jar), this is not of interest since a similar edit in sun-web.xml can append such entries to the classloader list. I'm just looking for an ability to [i]insert[/i].
> [Message sent by forum member 'jess_holle' (jess_holle)]
>
> http://forums.java.net/jive/thread.jspa?messageID=241862
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

jess_holle
Offline
Joined: 2003-06-11

First off, the docs make it sounds like paths are relative to your docroot, which is why I tried ".". Paths [i]are[/i] docroot relative in /'s extra-class-path attribute.

Second, it's clear libraries won't work here for a couple of reasons. I need to add the docroot directory itself as a classloader entry, not a jar. I need this to be added to the web app classloader, not a parent thereof. The classes in docroot reference classes in WEB-INF/lib/*.jar (and vice versa) -- they have to be loaded by the same classloader.

Why libraries should allow jars and not directories is beyond me -- I would have still expected it to add my "codebase" directory to the classloader when I gave the full path. In the end, however, this is irrelevant since the libraries feature inserts a separate classloader rather than a classloader entry.

jess_holle
Offline
Joined: 2003-06-11

I did a little digging in the Glassfish source.

Lo and behold it uses the same old classes from Tomcat that I subclass and extend, namely org.apache.catalina.loader.WebappClassLoader, org.apache.naming.resources.FileDirContext, and org.apache.catalina.loader.WebappLoader.

Is there a simple way I can tell Glassfish to use my own subclasses of these classes for my web app [as there is for Tomcat]?

whartung
Offline
Joined: 2003-06-13

Just as an aside, can you tell us why you need this? And why it's easier to rework the container than it is to adjust the packaging of the application?

Mind, I'm not suggesting you change the path you're going down, as you've had some success in the past. But I am curious what your application is doing that it needs this versus the standard applications packaging.

jess_holle
Offline
Joined: 2003-06-11

First I should let on that our enterprise application is quite large in size, has been selling for around a decade, and new versions are still being sold (including upgrades to existing versions). As such it predates the existence of servlets, EJBs, etc. Also any repackaging task would be quite enormous. We've considered it certainly, but small tweaks to loaders are [i]much[/i] more cost effective.

The issue here boils down to classes and other resources that are shared by multiple tiers, client, web app, and [custom, pre-EJB] app server. There are many resources that are used by all these tiers.

Further applets load classes from the docroot except where they're available in client jars -- which in turn were really an optimized pre-packaging of classes from the docroot initially. For us this is still largely the case with the exception of 3rd-party jars used by the client, i.e. classes and other resources that might be used by a client reside relative to the docroot and then are gathered into client jars by tooling based on runtime usage testing. Client jars are not guaranteed to be complete and requests for other applet resources fail over to docroot.

Given the client applet situation we started down a path of docroot being the first entry in our classpath even before servlets existed. When servlets came around it always struck me as wrong that there was no standard location in the web app where the client tier and server tier could share the same resources -- but at any rate we altered servlet engine loaders or [less preferably] overall classpaths (thus destroying all web app isolation) to address the situation and continued sharing resources between the client and server tier.

jess_holle
Offline
Joined: 2003-06-11

Just one more note: our application [i]generally[/i] works with docroot at the end of the web app classloader. The load order difference occasionally causes issues that only impact deployments with this load order issue (e.g. Sun Java Web Server too) since changes to classes/resources in docroot get overshadowed by those in WEB-INF/lib/*.jar that are only intended to be defaults, for instance.

km
Offline
Joined: 2005-10-28

Looks like you should be using --libraries option on deployment of application. That way, you
could keep your libraries anywhere.

See http://blogs.sun.com/sivakumart/entry/classloaders_in_glassfish_an_attempt for details.

Just curious: You have different versions of same classes in docroot and the web-app?

Regards,
Kedar

jess_holle
Offline
Joined: 2003-06-11

Thanks for the pointer, I'll definitely read the article.

Are you saying I can put a docroot directory (not a jar) at the front of my webapp classloader URL list and then just have it followed by WEB-INF/classes and WEB-INF/*.jar? [I don't want to have to explicitly list the jars either.]

Ideally I still want this all at the web app loader level so I can still have multiple non-colliding web apps.