Skip to main content

Re: Service calls from/to OSGI WAB Hybrid applications have wron

1 reply [Last post]
Joined: 2005-03-30

Then the layer that makes the spring bean available as osgi service has to be responsible for making sure the service is called in correct context. You can use blueprint or something else for spring integration.

Sent from my Android phone, please excuse me for its brevity.

-----Original Message-----
From: []
Received: Wednesday, 28 Nov 2012, 20:41
To: []
Subject: Re: Service calls from/to OSGI WAB Hybrid applications have wron

Thanks for the info, Sahoo. I can see now what you mean, but let me explain
my setup. I'm not using any EJB technology, but instead the Spring framework
to provide transactions, dependency injection, ect. So here the assumption
that some service class will not be interacting with JavaEE no longer holds
true. The service implementation that implements the OSGI service can be a
Spring bean, and it can be wired with other services or DAOs. Spring knows
about entityManagerFactories, ect by wiring them up from
applicationContext.xml through JNDI lookups. Also Spring will create
transactions if you specify so, so it will also be making lookups to the
UserTransaction as apart of its AOP interceptor. And therefore we will
definitely need a JavaEE context. What would be the proper way to use Spring
in a Web Application Bundle, is it not feasible at all? Note: I have managed
to get everything working, even this part with a workaround.


[Message sent by forum member 'chejavara']

View Post:

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2012-11-27

I have looked into this, there is nothing that makes the service come into the correct JavaEE context with Spring.

Spring attempted to insert Proxy (with Spring DM), but at best this proxy would only try to adjust the Thread Context Classloader. Gemini Blueprint does exactly the same. Actually, it wouldn't make sense, there is nothing in the Enterprise OSGI Spec that specifies that this should happen.

As far as I know, the javaEE context is buried in the thread locals which only Glassfish knows how to read and set.