When WAB1 calls WAB2's service and the service is actually a Java EE
component like a local EJB, then the Java EE context will be switched to
EJB's context during the call of the EJB. If the service is a pure OSGi
service, then it has no JavaEE context associated with it, so it
inherits whatever is in the caller's thread. However since it is a pure
OSGi component, it does not care about JavaEE context. It has its own
BundleContext to interact with its universe.
Thread's context class loader switch happens for remote components only.
Sahoo
On Wednesday 28 November 2012 12:56 AM, forums_at_java.net wrote:
> I have a question about how service calls are supposed to work with
> OSGI Web
> Application Bundles Lets say I have WAB1 that tracks and calls an OSGI
> service, that WAB2 registered. When the actual service is called from
> WAB1, I
> can see that there is a 'Context' associated that is only for WAB1. (More
> precisely, this is a ComponentInvocation (WebComponentInvocation) that is
> stored as a inheritable thread local as 'frames' variable of
> InvocationManagerImpl.) But when WAB1 calls a service that is
> implemented in
> WAB2, then we are still under the context of WAB1, it has not been
> switched.
> Even if a new thread is started in service implementation in WAB2, it
> will
> still 'inherit' the context of WAB1. So that means we will not be able
> to see
> the JNDI context of WAB2, and we will not be able to get any persistence
> units defined in WAB2 even though we are executing inside WAB2. Basically
> anything that would need to be aware of the fact that WAB2 has its own
> context. The Thread Context Class Loader will also be wrong since it
> is still
> belonging to WAB1. I would appreciate if Sahoo or someone can shed
> some light
> on this matter?
>
> --
>
> [Message sent by forum member 'chejavara']
>
> View Post: http://forums.java.net/node/892749
>
>