quality@glassfish.java.net

FW: [Issue 5647] New - class loader for WAR's inside an EAR should try load before delegating by default

From: Wim Verreycken <wim_at_pizzastop.be>
Date: Tue, 26 Aug 2008 17:37:39 +0200

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?