0
votes

I have an OSGi project that, among others, contains one bundle with JPA annotated domain models and another which uses Eclipselink as persistency provider. The latter instantiates the EntityManager using a configuration parameter to determine the JDBC driver's class name.

Now, the bundle with the models needs to be able to see the JDBC driver, I think, that is because eclipselink uses the classloader of the model classes to load it. This has the unwanted side effect that I need to explicitly declare an Import-Package directive in the model's bundle to pull in the driver. Swapping out the driver via OSGi then isn't easy anymore (I need to regenerate the manifest), which defeats the purpose of using OSGi in the first place.

Since JDBC drivers all implement the same interface, what I would like to do is put database drivers in their own bundle, register them with the OSGi container under their common interface name and have eclipselink use whatever is available. But I can't see how to do that, because it seems the driver is instantiated by eclipselink, meaning I can't instatiate it elsewhere and have eclipselink be oblivious of the actual class name.

This seems like a very typical thing to do. I guess there's already a solution out there?

This post by Shaun Smith of Oracle from earlier this year suggests that there maybe isn't, but it also indicates that the demand for it seems to be quite real.

1

1 Answers

2
votes

Sounds like a shortcoming of eclipselink. I suggest to file a bug/feature request for this.

A workaround for your problem is to introduce another bundle into the picture which imports from your model and the JDBC driver bundle and then point eclipselink to that new bundle.

That means you model is free from any reference to the JDBC stuff, you make the connection in a new bundle. The drawback is that you need such a bundle per supported JDBC driver but these bundles are pretty much boiler plate code, so it should be simple to create another one in a few moments.

Another solution might be to write your own JDBC driver which simply wraps the real driver. In your code, you can use OSGi discovery to find which real drivers are available while nothing seems to change for eclipselink.