|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:
... not really, the class loader must be set on a thread every time a new
thread comes in our code (right? :)))
Ok most threads come through the container invoker (invocation from web or
other j2ee stacks (tomcat)... that is taken care of (it was my point 1).
The other points of independent entry are obviously your passivating thread,
but also the commiting thread on the Tx.
So... don't worry about anything else that setting the class loader on the
passivating thread. You can set it for once if your thread is linked to the
container.
|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 ?
Again, don't focus on the different methods, try to see the 4 points of
entry and the 4 thread that come in and you will be set (hey! we missed it
until yesterday :)))
|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 ?) ?
The thread context class loader is linked to the application and has
visibility on the jar and ear and what not. But that class loader most
likely doesnt' see the classes of the container including the passivating
cache policy. forName on the system classes is the right way to go for now.
Note that at some point we might want to upgrade parts of the container on
the fly and then the visibility will be given by a "module" jar that is
dynamically managed (as opposed to linked at startup time by JMX, the way we
do it today).
|
|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 ?
again follow the thread,
marc
|
|Bye
|
|Simon
|
|
