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.6.2.4.8.
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 problem?
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.
thanks 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
