| Re: [eclipselink-users] EJB 3.0 usage |
Gordon Yorke wrote:
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! ;-)I do not believe any of the committers have taken this on yet but we would be glad to hear your ideas. 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. 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? 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? 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? As you can tell we're very keen to be *the* OSGi friendly JPA implementation and as I'd said on the forum, your participation is much appreciated! OSGi is new to most of the EclipseLink committers and there is no substitute for practical experience. Shaun
--
 Shaun Smith | Principal Product Manager | +1.905.502.3094 Oracle TopLink 110 Matheson Boulevard West, Suite 100 Mississauga, Ontario, Canada L5R 3P4 |