Hey,
> > btw I think more about this and we really have 4 points of
> entry with
> > threads...
> >
> > 1- normal invocation (enters through container invoker)
> > 2- commit through Synchronization (session and entity)
> > 3- passivation (independant thread)
> > 4- time outs
> >
> > on ALL these 4 entries the context class loader must be
> set, the error we
> > are seeing is in 2 but all the others must be done (well 1
> is done at
> > least).
> >
> > Simone can you look into 3 (do
> >
> Thread.currentThread().setContextClassLoader(container.getClas
> sLoader()) or
> > something like that, before leaving the thread do the rest since the
> > ejbPassivate WILL work on the bean and need that visibility
> on its classes).
>
> This depends on if there is one passivation thread/bean or one p.
> thread/server. If one thread is used then this is needed,
> otherwise the
> CL should be inherited when the passivation startup code does new
> Thread(). Might be a good idea to add it in either case, just to be
> sure.
If I've well understood, every time there is an invocation on the bean
instance the thread ctx CL (TCCL) must be set to the container CL (CCL), as
you suggested above (so for example all the ejbXXX methods, the new
isModified, etc). My questions:
1) how much other code should have the TCCL set to the CCL ? I mean: the fix
made in the synchronization int'r in beforeCompletion uses the TCCL not only
for the isModified invocation, but also for storeEntity. This calls ejbStore
(with the TCCL set to the CCL, which is OK) but also store.storeEntity:
should this last call have the TCCL set to the CCL or it does not matter ?
What if loads classes doing its job ?
2) Which classloader should I use to load classes in initialization code ?
For example, I load the cache policy class and invoke its constructor using
reflection, which CL should I use ? It is enough getClass().forName(cls) or
I should use the TCCL (that I should set to which CL ?) ?
Question 1 arises from the fact that I could set the TCCL to the CCL before
calling contaner.getPersistenceManager.passivate(activate)Entity(Session),
but this can be done once and cleanly in the persistence manager, better
than in many places that call the persistence manager, what do you think ?
Bye
Simon
