geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
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 20:24:56 GMT

On Feb 1, 2005, at 11:41 AM, Jeremy Boynes wrote:

> 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).

Ahh, it's not in the ejb spec but in the j2ee spec J2EE.

So, right now we only set the TCCL:
--entering a web app
--in the jndi and ejbd in openejb
--in mdb call handling

and, to the wrong value, in the thread pool.

We do not switch classloaders going from a web app to an ejb module.  I 
don't think this is correct, since an ejb would get the class loaded 
from the web app classloader rather than its own.  But I guess you 
shouldn't duplicate classes like this in an ear? Does this cause a 

Can we detect calls from ejb's in one ear to another (or between 
standalone ejb apps)?  I'm unclear about whether "local" calls are 
allowed, and what exactly we do about "remote" calls in this situation.

Assuming we can detect any such cross-app calls and set the TCCL 
appropriately, it looks like all we need to do here is set the correct 
TCCL when the ejb timer worker gets started.

One way of detecting x-app calls would be by comparing the jsr-77 
object names, although I'm not quite sure where that would be done.

david jencks

> 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

View raw message