On Nov 29, 2007, at 12:41 PM, Shaun Smith wrote:
Gordon Yorke wrote:
I do not believe any of the committers have taken this on yet but we would be glad to hear your ideas.
Actually as I'd said in response to Bryan's forum post I have been digging into packaging EclipseLink for OSGi. I do have JPA, SDO and JAXB plugin test cases running and have verified that jars I've generated with a Manifest.mf and the necessary OSGi properties set can also be used in a non-OSGi environment. Apparently the story that bundles are just jars with additional entries in the Manifest.mf is true! ;-)
Bryan Hunt wrote:
The biggest issue with getting Hibernate to work with the OSGi plug-in architecture is, of course, the plug-in classloader. Hibernate can't find your Entities defined in plug-ins without some help. The problem was solved by a combination of the Eclipse buddy policy, and playing games with the context classloader and persistence.xml.
I'd like to compare notes on this. I haven't had to play around the context classloader--I just setup the right Equinox buddy policy.
As I recall, Hibernate uses the current thread's context classloader:
Thread.currentThread().getContextClassLoader()
which didn't work with bundle classloading. I can't remember if it was because OSGi doesn't set the context classloader, or if it had to do with how I separated the JPA API from the implementation into their own bundles.
BTW, I would suggest looking at the "dependent" policy instead of the "registered" policy. It might make life easier for clients.
Of course I haven't tackled byte code weaving yet. I have a few scenarios working and the one that is most interesting from a classloader perspective looks like:
unannotated-pojos.jar eclipselink.jar
^ ^
| |
tests-with-orm.xml-and-persistence.xml
In this scenario eclipselink is able to load the classes in unannoted-pojos.jar.
Another problem we had was with the persistence.xml file. Part of our application is designed as a set of frameworks that are designed to be extensible, and some of these frameworks use the EntityManager. We needed a way to make the persistence.xml file extensible. The solution was to create the persistence.xml file on-the-fly at runtime when we initialize the EntityManagerFactory.
AFAIK we always try to load persistence.xml from META-INF\persistence.xml so being able to either pass in a Stream, String, or alternate file location/file name to create an EntityManagerFactory would be a new feature. Can you file an enhancement request for?
I'll submit an enhancement request. BTW, are you by any chance using URL to access the persistence.xml file? Hibernate uses the URL class which has enough hooks to provide the persistence.xml on-the-fly.
A side benefit of creating the persistence.xml at runtime is the ability to easily switch between different database vendors.
In a non-OSGi environment, EclipseLink does a good job of figuring out what database platform (dialect) to use based on the JDBC driver. If using either Derby or Oracle DB I don't bother specifying it in my persistence.xml.
We typically use MySQL for debug / test and DB2 for production. Switching databases is a simple matter of specifying which database plug-in to load in the launch configuration.
This is definitely a very nice feature. How do you connect the PU with the right JDBC plugin? Is the JDBC Driver made available through a service?
By PU, I assume you mean persistence unit? I currently use an extension to map a persistence context to a logical database connection managed by my JDBC persistence service. The JDBC persistence service in turn maps a logical connection to a physical connection specified as an extension. When I swap out JDBC drivers, I also swap out the physical connection specifications.
Our solution ties everything together through a persistence plugin that defines an extension point allowing other plug-ins to declare entities as an extension. This allows multiple plug-ins to contribute entities (as extensions) to the same persistence context. The plug-in also defines an OSGi service for obtaining an EntityManager. It also gives us the ability to manage the same Entity in multiple persistence contexts. We are not currently using this ability, but I can see a way we may use it in the future.
This sounds very cool and is the kind of thing we had talked about exploring in the original Project Proposal! Are you able to contribute code to the project?
I'd be willing to contribute assuming my architecture is reasonably close to where you want EclipseLink to go. I'll have to get certified by my company to make a contribution which takes some time, but I've been needing to do this anyway.
