Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <434A966E.5060507@apache.org>
Date: Mon, 10 Oct 2005 18:27:26 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Clarifying classloading in 2.2 [was Re: Classloader changes]
References: <434A73A1.9050604@apache.org>
In-Reply-To: <434A73A1.9050604@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Carsten Ziegeler wrote:
> I hope that we can remove some of the old class loader/class path
> handling in 2.2 and make everything simpler.
> 
> In 2.1.x we had a boolean parameter (in web.xml) which could be used to
> set the Cocoon class loader (the one used to instantiate Cocoon) as the
> thread context class loader.
> 
> In addition, we could define extra class paths in web.xml (containing
> directories/jars I think) which were added to the class path as well and
> finally we have parameters to force load classes (e.g. for jdbc drivers).
> 
> With real blocks I think we should always add our class loader as the
> thread context CL (this is the current implementation) and we should
> forget about defining additional class paths.

yes, with the rise of blocks there shouldn't be a need for this anymore.

> I'm not sure about the force loading stuff.

I'd skip it.

> 
> In addition I think we should always use the paranoid class loader to
> avoid class loading problems. A common problem are either Xalan and
> Xerces where you forgot to put the latest version (used by Cocoon) into
> the endorsed lib. Or if the application server uses his own version of
> let's say commons-logging/log4j and you want to use a different one in
> Cocoon.

+1

> 
> So, the most important question is: does using an own class loader
> inside a web app work in all engines, is it allowed, and is it allowed
> to set the thread context CL?

Unfortunatly the spec doesn't say anything whether using your own classloader is 
allowed or not:

[...]
J2EE.6.2.4.8 Context Class Loader
---------------------------------
This specification requires that J2EE containers provide a per thread context 
class loader for the use of system or library classes in dynamicly loading 
classes provided by the application. The EJB specification requires that all EJB 
client containers provide a per thread context class loader for dynamicly 
loading system value JDBC™ 2.0 Extension Requirements 87
classes. The per thread context class loader is accessed using the Thread method
getContextClassLoader.

The classes used by an application will typically be loaded by a hierarchy of
class loaders. There may be a top level application class loader, an extension 
class loader, and so on, down to a system class loader. The top level 
application class loader delegates to the lower class loaders as needed. Classes 
loaded by lower class loaders, such as portable EJB system value classes, need 
to be able to discover the top level application class loader used to dynamicly 
load application classes.

We require that containers provide a per thread context class loader that can
be used to load top level application classes as described above.

[...]


-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de