On Tuesday 28 February 2012 09:35 PM, Kirk Rasmussen wrote:
> Sahoo suggested using an interceptor as follows:
>
> @AroundInvoke
> Object setEM(InvocationContext ctx) throws Exception {
> log("entering setEM()");
> utx.begin();
> em = emf.createEntityManager();
> em.joinTransaction();
> try {
> Object result = ctx.proceed();
> utx.commit();
> return result;
> } catch (Exception e) {
> utx.rollback();
> throw e;
> }
> finally {
> em.close();
> log("exiting setEM()");
> }
>
> This a nice work around but its container specific code that I wouldn't
> need in Aries for example making my code non-portable which makes me
> sad. IMHO for Enterprise OSGi to take off mainstream issues like this
> need to be resolved. OSGi applications need to support managed JPA,
> declarative transactions and security as transparently and as portably
> as EJB3.
>
I don't understand what is container specific here? Interceptor is a
supported technology in EE platform - nothing specific to GlassFish.
That code will work exactly same way in JBoss, WebLogic and WebSphere.
Aries required you to write some XML instead of this code - that's the
way I like to see things.
> In regards to Hibernate vs EclipseLink. Is it possible to use Hibernate
> enhanced classes from external bundles? I did a proof of concept using
> Hibernate 4 where I embedded all the 3rd party libraries it needed
> within the bundle (WHAT A PITA!) along with the JPA entity classes,
> persistence.xml and a simple EJB service I got it to work but I never
> shared the entity classes outside the bundle. For example if I had a
> service bundle and a web bundle could the service bundle return JPA
> entities from an OSGi service to the web bundle safely (e.g. lazy
> associations, 2nd level caching).
I would expect it to work. Just export the packages of JPA entities from
the bundle containing the entities. Give it a try and let me know.
Sahoo