Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Gemini » Gemini JPA Mission Statement?
Gemini JPA Mission Statement? [message #682551] Sat, 11 June 2011 12:19 Go to next message
Harald Wellmann is currently offline Harald WellmannFriend
Messages: 34
Registered: July 2009
Location: Hamburg, Germany
Member
It's hard to get an idea of what Gemini JPA is actually trying to achieve. (The same is true for so many other Eclipse subprojects...)

The most tangible information I could find is this presentation.

So Gemini JPA "is delivering the OSGi JPA Service specification reference implementation"? I wasn't aware of any official OSGi reference implementations, Core or Enterprise, and the OSGi Alliance site or search engines do not mention the subject either.

My understanding of the OSGi JPA spec is that persistence providers, persistence bundles and clients bundles should be able to work together in OSGi, but in a decoupled manner. I'd say this is compatible with what I read from the Gemini JPA presentation.

However, taking a look at the 1.0.0.RC1 download, it's enough to open the org.eclipse.gemini.jpa manifest to see a Require-Bundle dependency on Eclipselink.

So apparently Gemini JPA is designed to work with Eclipselink and Eclipselink only, which is clearly insufficient for a reference implementation of the OSGi JPA spec, in that no other JPA provider will be able to work with this implementation of the JPA service.

AFAIK there are two projects working in this area, Eclipse Gemini and Apache Aries (is the zodiac naming a mere coincidence....?), and while not claiming to be any kind of reference, Apache Aries is not flawed by tying itself to any given provider.

Are there any plans to break the hard link between Gemini and Eclipselink? If not, I'll better stick with Aries...

Best regards,
Harald


[Updated on: Sun, 12 June 2011 14:23]

Report message to a moderator

Re: Gemini JPA Mission Statement? [message #682934 is a reply to message #682551] Sun, 12 June 2011 14:22 Go to previous messageGo to next message
Harald Wellmann is currently offline Harald WellmannFriend
Messages: 34
Registered: July 2009
Location: Hamburg, Germany
Member
I had another look at the OSGi Enterprise spec and at Aries, and it seems my understanding of the spec was biased by what I'd seen in Aries a few months ago. In fact, there is no such thing as a JPA Service (or container or broker) in the spec, in spite of the chapter title.

Nevertheless, I do think it's a good idea to have one, shifting the burden of tracking persistence bundles and data sources and implementing OSGi extensions from the persistence provider to one central place, just by registering a javax.persistence.spi.PersistenceProvider service.

The point is, you currently cannot use Eclipselink with Aries, or OpenJPA with Gemini. But given that JPA implementations are more or less pluggable in Java SE and Java EE, you'd expect the same in OSGi.

Best regards,
Harald
Re: Gemini JPA Mission Statement? [message #683332 is a reply to message #682551] Mon, 13 June 2011 14:28 Go to previous messageGo to next message
Michael Keith is currently offline Michael KeithFriend
Messages: 243
Registered: July 2009
Senior Member
Hi Harald,

You ask some good questions. Here are some answers.

Quote:
I wasn't aware of any official OSGi reference implementations, Core or Enterprise, and the OSGi Alliance site or search engines do not mention the subject either.

As with most software specifications, the OSGi Alliance specs require Reference Implementations and have a set of Compliance Tests (see the OSGi Alliance Membership section at the bottom of the OSGi Alliance home page). Although the CTs are only available to members/licensees, the RIs are available to the public. As you pointed out, however, they are not very visible and that is precisely why we created the Gemini project -- to provide visibility and community around the spec implementations.

Quote:
My understanding of the OSGi JPA spec is that persistence providers, persistence bundles and clients bundles should be able to work together in OSGi, but in a decoupled manner

Correct, but the spec describes what each provider is supposed to implement in order for this to occur. It does not describe an implementation of some additional layer that supports all providers.

Quote:
So apparently Gemini JPA is designed to work with Eclipselink and Eclipselink only, which is clearly insufficient for a reference implementation of the OSGi JPA spec, in that no other JPA provider will be able to work with this implementation of the JPA service.

An OSGi implementation for each provider is exactly what the spec dictates. The OSGi EEG decided that in order for a provider to work properly in OSGi it needs to add explicit support in the form of the impl details described in the OSGi JPA chapter. This is exactly what Gemini JPA did and the source code that became Gemini JPA passed the CT test suite as the RI for the Enterprise 4.2 release.

Quote:
Apache Aries is not flawed by tying itself to any given provider. Are there any plans to break the hard link between Gemini and Eclipselink?

As I think you have since learned, Aries is coupled to its own JPA provider, and neither Gemini nor Aries is flawed by doing so. This is precisely what the OSGi spec intended.

Quote:
I had another look at the OSGi Enterprise spec and at Aries, and it seems my understanding of the spec was biased by what I'd seen in Aries a few months ago. In fact, there is no such thing as a JPA Service (or container or broker) in the spec, in spite of the chapter title.

Perhaps the attempt at consistency in the spec was a little misleading, here, but you are correct that there is no *one* JPA service, but rather a collection of JPA-based services for supporting persistence units. There is a single provider service for each provider, and generally an EMF service and an EMF Builder service for each persistence unit.

Quote:
Nevertheless, I do think it's a good idea to have one, shifting the burden of tracking persistence bundles and data sources and implementing OSGi extensions from the persistence provider to one central place, just by registering a javax.persistence.spi.PersistenceProvider service.

This was exactly what was initially proposed, however the EEG decided that was not necessary on the basis of what I mentioned earlier about each of the providers needing to explicitly support OSGi.

Quote:
The point is, you currently cannot use Eclipselink with Aries, or OpenJPA with Gemini. But given that JPA implementations are more or less pluggable in Java SE and Java EE, you'd expect the same in OSGi.

Support for the JPA spec is intended to be provider-specific, so just think of Gemini JPA as the EclipseLink provider add-on for OSGi support and Aries as the one for OpenJPA. Pick whatever project you want to use based on the JPA provider you want, not on the merits of the bit of code that plugs that provider into OSGi. Note that this does not affect pluggability in any way, since there is no limitation on the providers that can be co-resident. The spec is designed so that you can have EclipseLink and OpenJPA (and their accompanying OSGi JPA supporting impls) each supporting persistence units in the same running framework.

Hope this helps, somewhat.

-Mike
Re: Gemini JPA Mission Statement? [message #684006 is a reply to message #683332] Tue, 14 June 2011 20:53 Go to previous messageGo to next message
Harald Wellmann is currently offline Harald WellmannFriend
Messages: 34
Registered: July 2009
Location: Hamburg, Germany
Member
Hi Mike,

thanks a lot for your detailed comments and the background on the OSGi EEG. This helps to clarify the goals of Gemini JPA.

Quote:

Quote:

Nevertheless, I do think it's a good idea to have one, shifting the burden of tracking persistence bundles and data sources and implementing OSGi extensions from the persistence provider to one central place, just by registering a javax.persistence.spi.PersistenceProvider service.


This was exactly what was initially proposed, however the EEG decided that was not necessary on the basis of what I mentioned earlier about each of the providers needing to explicitly support OSGi.


I agree this is not necessary, but I thinks it's a more elegant solution.

I took Eclipselink minus the *.jpa.osgi bundle/fragment, added a trivial bundle of my own, containing just an Activator which registers Eclipselink's implementation of javax.persistence.spi.PersistenceProvider an as OSGi service, and that was enough to make Eclipselink work with Aries JPA and JNDI without using anything of Gemini.

The orchestration of persistence bundles, persistence providers and client bundles is not exactly trivial, so why should every persistence provider have to reimplement it?

All in all, I think the OSGi JPA and JTA specs are somewhat too limited to be useful in practice.

In the end, I would like to be able to take a Java EE 6 WAR, repackage all WEB-INF/lib/*.jar libraries as separate OSGi bundles, install them in an OSGi Enterprise container, and use @PersistenceContext, @TransactionAttribute and @Inject and even @Stateless.

Just being able to access an EntityManagerFactory and a UserTransaction as OSGi services isn't too exciting - once you get used to declarative transactions, you don't want to hand-code them any more.

The same goes for XML configuration. Blueprint XML just feels like a regression to J2EE 1.4 or pre-annotation Spring.

Using the Spring internals of Gemini Blueprint, I was able to replace most XML by standard @Inject and @TransactionAttribute (not even using Spring's own @Autowired and @Transactional).

But of course, this is an implementation detail of Gemini Blueprint, and my bundles with these annotations wouldn't work on Aries Blueprint.

Aries has its own set of annotations, which is nice, but again causes supplier lock-in.

I think the OSGi EEG should standardize annotations and take CDI as a starting point for that, trying to express all interactions with the OSGi service registry by means of @Qualifiers and CDI extensions.

Regards,
Harald




Re: Gemini JPA Mission Statement? [message #684910 is a reply to message #684006] Thu, 16 June 2011 13:13 Go to previous message
Michael Keith is currently offline Michael KeithFriend
Messages: 243
Registered: July 2009
Senior Member
Quote:
Hi Mike,
thanks a lot for your detailed comments and the background on the OSGi EEG. This helps to clarify the goals of Gemini JPA.
Quote:

Quote:

Nevertheless, I do think it's a good idea to have one, shifting the burden of tracking persistence bundles and data sources and implementing OSGi extensions from the persistence provider to one central place, just by registering a javax.persistence.spi.PersistenceProvider service.

This was exactly what was initially proposed, however the EEG decided that was not necessary on the basis of what I mentioned earlier about each of the providers needing to explicitly support OSGi.

I agree this is not necessary, but I thinks it's a more elegant solution.

Totally, and that is why both I and the IBM Aries guy who helped work on the OSGi JPA spec initially proposed it that way and pushed hard for it. However, we failed to convince enough of the rest of the expert group, so sadly the spec became a task for every provider. Kind of ironic in what is supposed to be a reusable component framework, eh?

Quote:

I took Eclipselink minus the *.jpa.osgi bundle/fragment, added a trivial bundle of my own, containing just an Activator which registers Eclipselink's implementation of javax.persistence.spi.PersistenceProvider an as OSGi service, and that was enough to make Eclipselink work with Aries JPA and JNDI without using anything of Gemini.

That's great! Unfortunately you are probably not going to get dynamic weaving to work that way, though, because there is no callback from Aries into the provider to do that, but fortunately EclipseLink can work without weaving, or you can do it statically before installing the persistence unit bundle.

Quote:

The orchestration of persistence bundles, persistence providers and client bundles is not exactly trivial, so why should every persistence provider have to reimplement it?

You're preaching to the choir, dude. When I started Gemini I fully thought that we would be be specifying it that way (you will even notice the presence of an OSGiJpaProvider interface) but life doesn't always turn out the way we expect Smile

Quote:
All in all, I think the OSGi JPA and JTA specs are somewhat too limited to be useful in practice.

Well, for all of the people that are used to using JPA in an SE environment (and there are many) they basically get what they want. For those that are used to using JPA in EE then we are a long way from that. OSGi standards are probably never going to offer the same experience, but they don't need to because app servers can do that themselves anyway.

Quote:
In the end, I would like to be able to take a Java EE 6 WAR, repackage all WEB-INF/lib/*.jar libraries as separate OSGi bundles, install them in an OSGi Enterprise container, and use @PersistenceContext, @TransactionAttribute and @Inject and even @Stateless.

Just being able to access an EntityManagerFactory and a UserTransaction as OSGi services isn't too exciting - once you get used to declarative transactions, you don't want to hand-code them any more.

The same goes for XML configuration. Blueprint XML just feels like a regression to J2EE 1.4 or pre-annotation Spring.

This is all true, but OSGi is not trying to be a full-fledged container. We have application servers like Glassfish to do that for us.

Quote:
I think the OSGi EEG should standardize annotations and take CDI as a starting point for that, trying to express all interactions with the OSGi service registry by means of @Qualifiers and CDI extensions.

Reinventing all of the EE technologies in OSGi is not the right approach. I think you just want your EE app servers, that already support all of the EE technologies that you know and love, to support more modularization.
Previous Topic:Influence Interface AOP Proxy on osgi:reference side
Next Topic:Can I replace Spring 3.0.0 with Spring 3.0.5?
Goto Forum:
  


Current Time: Tue Mar 19 02:14:32 GMT 2024

Powered by FUDForum. Page generated in 0.02368 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top