geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: svn commit: r149431 - in geronimo/trunk/modules: core/src/java/org/apache/geronimo/pool/ naming/src/java/org/apache/geronimo/naming/java/ timer/src/java/org/apache/geronimo/timer/jdbc/ timer/src/test/org/apache/geronimo/timer/
Date Tue, 01 Feb 2005 19:41:01 GMT
David Jencks wrote:
> 
> On Feb 1, 2005, at 11:13 AM, Jeremy Boynes wrote:
> 
>> Shouldn't the classloader come from the command rather than the pool?
> 
> 
> Well, I figure that if the command needs a particular classloader it  
> can set it itself.  It will have to do that on each thread use.  This  
> provides all threads from the poo with a useful generic classloader  
> rather than the App classloader that is there if you do nothing.  This  
> happens once per thread creation, and is sufficient to get jndi to  work.
> 

Using the GBean's classloader makes sense as a default for the pool - it 
means that, by default, commands would run with TCCL set to that 
supplied (which is that of the Configuration containing the GBean 
instance).

For any component, the TCCL should be that of the module that contains 
it (typically EAR but possibly that of a nested WAR). Things that are 
using the pool should not assume that the default classloader for the 
pool will be the correct one and should always have the command 
explictly set the TCCL (or do it downstream somewhere e.g. in an EJB 
Interceptor or in the web context handler).

Stuff might work simply because the pool and, for example, jndi are 
located in the same Configuration. However, I do not believe this is 
true in the general case.

--
Jeremy

Mime
View raw message