To finalize this monologue with myself, the dev's just mailed me that it is
indeed a bug and that it had already been reported (however based on
expected behavior and the gf dev guide only)
https://glassfish.dev.java.net/issues/show_bug.cgi?id=1351
Wim
-----Original Message-----
From: Wim Verreycken [mailto:wim_at_pizzastop.be]
Sent: dinsdag 26 augustus 2008 17:38
To: quality_at_glassfish.dev.java.net
Subject: FW: [Issue 5647] New - class loader for WAR's inside an EAR should
try load before delegating by default
I'm sorry about the typo (bij instead of by).
Wim
-----Original Message-----
From: wimv_at_dev.java.net [mailto:wimv_at_dev.java.net]
Sent: dinsdag 26 augustus 2008 17:34
To: wimv_at_dev.java.net
Subject: [Issue 5647] New - class loader for WAR's inside an EAR should try
load before delegating bij default
https://glassfish.dev.java.net/issues/show_bug.cgi?id=5647
Issue #|5647
Summary|class loader for WAR's inside an EAR should try
load b
|efore delegating bij default
Component|glassfish
Version|V3
Platform|All
OS/Version|All
URL|
Status|UNCONFIRMED
Status whiteboard|
Keywords|
Resolution|
Issue type|DEFECT
Priority|P5
Subcomponent|other
Assigned to|dochez
Reported by|wimv
------- Additional comments from wimv_at_dev.java.net Tue Aug 26 15:33:43 +0000
2008 -------
To be in line with the specs and to safeguard portability, classloader for
war's
inside ear files should try local load before delgating by default. This
would
also respect backwards compatibility. Moreover, according to the specs one
should be able to alter this setting without that causing any
ClassCastExceptions.
More below.
-----Original Message-----
From: Wim Verreycken [mailto:wim_at_pizzastop.be]
Sent: maandag 25 augustus 2008 20:12
To: quality_at_glassfish.dev.java.net
Subject: RE: FW: Isolate properties files between two WARs in an EAR
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 note 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."
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 I'd 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?
---------------------------------------------------------------------
To unsubscribe, e-mail: quality-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: quality-help_at_glassfish.dev.java.net