Hi all,
Because Manfred's solution imposes that one would need to change the source
code for it be possible to package multiple existing war's in an ear, I've
done some reading over the weekend.
I discovered HP-AS and WebLogic use a different approach for ears using one
web application classloader per web app which is not delegating by default.
At first seemed to me classloading semantics for ear's were kind of open to
interpretation.
This because of the differences in implementation, and because Sahoo replied
to the glassfish user list this was not mandated by the specs.
Taking a look at a draft document here :
https://glassfish.dev.java.net/nonav/javaee5/docs/DG/beade.html
learned me, that although not mandated by the specs, it is recommended.
"The Servlet specification recommends that the Web class loader look in the
local class loader before delegating to its parent.
To make the Web class loader follow the delegation model in the Servlet
specification, set delegate="false" in the class-loader element of the
sun-web.xml file."
(read further for why the latter should not be necessary)
Indead JSR-154 clearly states :
"SRV.9.7.2 : Web Application ClassLoader
It is recommended also that the application class loader be implemented so
that classes and resources packaged within the WAR are loaded in preference
to
classes and resources residing in container-wide library JARs."
Is does not mention this should not be the case when this web applicaton is
a subcomponent of an enterprise application.
So I was very supprised to find the final version of this draft (
http://docs.sun.com/app/docs/doc/820-4496/beagb?a=view) saying :
"Note -
For Technology Preview 2, the delegate value is ignored and assumed to be
set to true."
Imho the default for war's inside an ear file should be delegate=false
independently of the setting in sun-web.xml and this should not cause any
ClassCastExceptions.
This is also clearly the expected behabviour.
Now WHY is this expected behaviour?
Therefor we have to refer to the j2ee specifation :
p 126 says the following about it:
"A J2EE application should not assume that each component is loaded in a
separate class loader and has a
separate namespace. All components in a single application may be loaded
in a single class loader and share a single namespace. Note, however, that
it must be possible to deploy an application such that all components of the
application are in a namespace (or namespaces) separate from that of other
applications. Typically, this will be the normal method of deployment."
Clearly it is not the normal method of deployment on glassfish, according to
the above not it is even no longer possible on v3tp2!
further on page 127 it says :
"Any J2EE product must be able to accept a J2EE application delivered as a
.ear file or a stand-alone J2EE module delivered as a .jar,.war, or .rar
file (as
appropriate to its type). If the application is delivered as a .ear, an
enterprise bean
module devliered as a .jar file, or a web application delivered as a .war
file, the
deployment tool must be able to deploy the application (!) such that the
Java classes
in the application are in a separate namespace from classes in other Java
applications. Typically this will require the use of a separate class loader
for each
application."
It seems to me "application" is here meant as in "only the application"
whereas putting delegate="false" in sun-web.xml will do so for the entire
server.
So aside from being my opinion, expected behaviour and a recommandation of
JSR-154, it looks like a specification after all.
The default for war's inside an ear file should be delegate=false (instead
of true) independently of the setting in sun-web.xml (this is correct) and
this should not cause any ClassCastExceptions.
So do like to think of this as a bug.
Does anyone else concur?
Wim
-----Original Message-----
From: Manfred Riem [mailto:mriem_at_manorrock.org]
Sent: zaterdag 23 augustus 2008 19:32
To: quality_at_glassfish.dev.java.net
Subject: RE: FW: Isolate properties files between two WARs in an EAR
The easiest solution to that problem is to make sure the properties you are
loading for the instantiated class use the getResource method based on the
classloader for each of the web applications.
If log4j is not working it is because of the way Log4J does initialization,
and
that really is a design flaw in their implementation.
Manfred
From: Judy.J.Tang_at_Sun.COM [mailto:Judy.J.Tang_at_Sun.COM]
Sent: Saturday, August 23, 2008 11:22 AM
To: quality_at_glassfish.dev.java.net
Subject: Re: FW: Isolate properties files between two WARs in an EAR
Thanks Wim for forwarding the email. Let's see how others think.
Judy
Wim Verreycken wrote:
Just copying from the glassfish user list, felt it was worth mentioning.
Never came across this, but surely I would find it annoying.
Although not mandated by the specs (so not a bug) this is expected behavior.
(Suppose you have 2 wars in you ear using log4j, but you want them to use
different settings?)
wim
-----Original Message-----
From: Sanjeeb.Sahoo_at_Sun.COM [mailto:Sanjeeb.Sahoo_at_Sun.COM] On Behalf Of
Sahoo
Sent: zaterdag 23 augustus 2008 4:49
To: users_at_glassfish.dev.java.net
Subject: Re: Isolate properties files between two WARs in an EAR
I don't think there is any way to achieve it in GlassFish. Even if you
achieve it, it's highly non-portable, as the spec does not mandate
classes/resources from one war to be isolated from another.
Thanks,
Sahoo
glassfish_at_javadesktop.org wrote:
Hi!
I am using glassfish v2 and have an EAR application with two WARs inside.
I put all the jars common to both in the EAR root level and only the
specific jars inside each WAR WEB-INF/lib.
I have a library (displaytag.jar) in the two WARs and the configuration of
displaytag is made by a properties file. Because each of the WARs have
different configurations, I put a displaytag.properties file in each
WEB-INF/classes and a displaytag.jar in each WEB-INF/lib.
The problem is that when one application loads the displaytag.properties,
the other uses the same properties, ignoring its own properties file. Is
there a way to solve this problem without using the class-loader
delegate="false" configuration in sun-web.xml?
If I use class-loader delegate="false" my application begin to have
problems with ClassCastExceptions. In this case, should I put all the jars,
its dependencies and resources (xml, properties files) in the same
classloader?
Thanks!
[Message sent by forum member 'renato_rka' (renato_rka)]
http://forums.java.net/jive/thread.jspa?messageID=294915
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: quality-help_at_glassfish.dev.java.net