[i]Not[/i] using Eclipselink, the default persistence provider of Glassfish, has the advantage that upgrading the persistence provider to a newer version can be trivial.
For example, I use an all-in-one-WAR deployment, where the WAR and all dependencies, including my persistence provider Hibernate, are controlled by Maven. For upgrading Hibernate, I simply change a version property in my parent POM and then rebuild and redeploy my web app.
I haven't tried it, but I suppose with Eclipselink, it wouldn't work to simply include a newer version in my WAR, because the older one from the container would still be used due to class loader issues.
In fact, this note
http://blogs.sun.com/GlassFishPersistence/entry/updating_eclipselink_bundles_in_glassfish
tells you to replace the Eclipselink modules in the Glassfish installation.
Now I don't want to mess with my app server installation just to plug in an alternative JPA provider. Surely there must be a way of having a provider in application space (Eclipselink or not) simply override the default provider in container space, with all the OSGi and hk2 machinery used under the hood?
Another question: Given that many development or even production environments have just a single application running in a single domain on Glassfish, are there any significant differences between the following deployment options:
1) JPA provider included in WAR/EAR
2) JPA provider installed in domain-dir/lib (as recommended by Glassfish App Dev Guide)
3) JPA provider installed in glassfish/modules
Regards,
Harald
[Message sent by forum member 'hwellmann']
http://forums.java.net/jive/thread.jspa?messageID=478480