glassfish
  1. glassfish
  2. GLASSFISH-14134

[JPA] Allow JPA in Java SE mode from OSGi context

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_ms07
    • Component/s: OSGi-JavaEE
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: Linux

    • Issuezilla Id:
      14,134

      Description

      Hi *,

      I just stumbled across a problem:

      I have an OSGi bundle that contains an activator which then calls some class
      which itself tries to get an EntityManagerFactory programmatically using the
      standard JPA utility class javax.persistence.Persistence:

      emf = Persistence.createEntityManagerFactory("jpa-test");

      The JPA unit is declared like this (persistence.xml):

      <persistence-unit name="jpa-test" transaction-type="JTA">
      <jta-data-source>jdbc/__default</jta-data-source>
      </persistence-unit>

      As the container should find an appropriate persistence provider using the
      services mechanisms I don't specify one here.

      The error I get is:

      INFO: Error while starting bundle:
      file:/srv/servers/glassfish/v31-b25/glassfish3/glassfish/domains/domain1/autodeploy/bundles/osgi.jpa-1.0-SNAPSHOT.jar:
      org.osgi.framework.BundleException: Activator start error in bundle
      org.glassfish.test.osgi.jpa [287].
      INFO: org.osgi.framework.BundleException: Activator start error in bundle
      org.glassfish.test.osgi.jpa [287].
      INFO: at org.apache.felix.framework.Felix.activateBundle(Felix.java:1869)
      INFO: at org.apache.felix.framework.Felix.startBundle(Felix.java:1739)
      INFO: at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:922)
      INFO: at
      org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1136)
      INFO: at
      org.apache.felix.fileinstall.internal.DirectoryWatcher.start(DirectoryWatcher.java:1122)
      INFO: at
      org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1115)
      INFO: at
      org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:433)
      INFO: at
      org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241)
      INFO: Caused by: javax.persistence.PersistenceException: No Persistence provider
      for EntityManager named jpa-test
      INFO: at
      javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
      INFO: at
      javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
      INFO: at
      org.glassfish.test.osgi.jpa.EMFactoryInitializer.init(EMFactoryInitializer.java:21)
      INFO: at org.glassfish.test.osgi.jpa.Activator.start(Activator.java:13)
      INFO: at
      org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:633)
      INFO: at org.apache.felix.framework.Felix.activateBundle(Felix.java:1822)
      INFO: ... 7 more

      I also tried to overcome this problem with specifying the provider in the
      persistence.xml file but without any change. Also a change to RESOURCE_LOCAL and
      <non-jta-data-source> does not make any difference.

      Is this manual way of initializing JPA currently unsupported within OSGi in
      GlassFish?

      I tested promoted builds b24 and b25.

      The main reason I want to do this is because I'm currently about to bring Apache
      ODE nicely into the OSGi world without much impact but as long as EJB's are
      registered in JNDI after the OSGi activator started the bundle successfully I'm
      stuck to the programmatic initialization of JPA.

      Need some help here. In one and/or another way.

      P.S.: I'll attach a very simple test case.

        Activity

        Hide
        chaoslayer added a comment -

        Created an attachment (id=5189)
        Testcase (OSGi bundle with activator trying to start JPA persistence unit)

        Show
        chaoslayer added a comment - Created an attachment (id=5189) Testcase (OSGi bundle with activator trying to start JPA persistence unit)
        Hide
        chaoslayer added a comment -

        Well, I just read the OSGi spec v4.2 once again and now stumbled across the JPA
        service:

        http://www.osgi.org/javadoc/r4v42/index.html?org/osgi/service/jpa/EntityManagerFactoryBuilder.html

        That should resolve my problem if it where supported by GlassFish, which is not
        the case currently:

        org.osgi.framework.BundleException: Unresolved constraint in bundle
        org.glassfish.test.osgi.jpa [288]: Unable to resolve 288.0: missing requirement
        [288.0] package; (&(package=org.osgi.service.jpa)(version>=1.0.0))

        And I guess chances are not very well to get this into the final 3.1? This would
        solve a lot of problem for "legacy" applications/frameworks migrating step by
        step into the OSGi world.

        Show
        chaoslayer added a comment - Well, I just read the OSGi spec v4.2 once again and now stumbled across the JPA service: http://www.osgi.org/javadoc/r4v42/index.html?org/osgi/service/jpa/EntityManagerFactoryBuilder.html That should resolve my problem if it where supported by GlassFish, which is not the case currently: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.test.osgi.jpa [288] : Unable to resolve 288.0: missing requirement [288.0] package; (&(package=org.osgi.service.jpa)(version>=1.0.0)) And I guess chances are not very well to get this into the final 3.1? This would solve a lot of problem for "legacy" applications/frameworks migrating step by step into the OSGi world.
        Hide
        Sanjeeb Sahoo added a comment -

        No, currently there is no bundle that provides org.osgi.jpa in glassfish. In
        3.1, we will add the necessary support for this package as part of our OSGi/JPA
        implementation. This is a rough sketch of how it is supposed to work:

        We will use osgi/jpa implementation done in Eclipse Gemini Persistence project.
        Since Gemini Persistence is built on top of eclipselink, which is already
        present in GlassFish, one has to just install a couple of Gemini bundles to get
        the necessary OSGi/JPA support in GlassFish.

        Show
        Sanjeeb Sahoo added a comment - No, currently there is no bundle that provides org.osgi.jpa in glassfish. In 3.1, we will add the necessary support for this package as part of our OSGi/JPA implementation. This is a rough sketch of how it is supposed to work: We will use osgi/jpa implementation done in Eclipse Gemini Persistence project. Since Gemini Persistence is built on top of eclipselink, which is already present in GlassFish, one has to just install a couple of Gemini bundles to get the necessary OSGi/JPA support in GlassFish.
        Hide
        chaoslayer added a comment -

        Thanx for reporting back and really nice to hear that this is going into
        milestone 7.

        Show
        chaoslayer added a comment - Thanx for reporting back and really nice to hear that this is going into milestone 7.
        Hide
        chaoslayer added a comment -

        Did you manage to work on this one?

        I managed to get some module chain (although in theory; still have to verify
        that) including new versions of eclipselink and gemini:

        Milestone 2 of gmini.jpa has been shipped with "org.osgi.service.jpa" but has
        been outsourced directly into eclipselink since milestone 3. Therefore we'll
        have to update eclipselink too. And here comes the problem:

        Updates for eclipselink:

        • org.eclipse.persistence:javax.persistence:2.0.3
        • org.eclipse.persistence:org.eclipse.persistence.osgi:2.2.0-M5
        • org.eclipse.persistence:[eventually others here]:2.2.0-M5

        Gemini:

        • org.eclipse.gemini.jpa:1.0.0-M3-incubation

        I don't know the roadmap of EclipseLink but this could make some trouble if the
        final version 2.2.0 may interfere with the final release of GlassFish version 3.1.

        Whoever I'll give this combination a try and report back.

        Show
        chaoslayer added a comment - Did you manage to work on this one? I managed to get some module chain (although in theory; still have to verify that) including new versions of eclipselink and gemini: Milestone 2 of gmini.jpa has been shipped with "org.osgi.service.jpa" but has been outsourced directly into eclipselink since milestone 3. Therefore we'll have to update eclipselink too. And here comes the problem: Updates for eclipselink: org.eclipse.persistence:javax.persistence:2.0.3 org.eclipse.persistence:org.eclipse.persistence.osgi:2.2.0-M5 org.eclipse.persistence: [eventually others here] :2.2.0-M5 Gemini: org.eclipse.gemini.jpa:1.0.0-M3-incubation I don't know the roadmap of EclipseLink but this could make some trouble if the final version 2.2.0 may interfere with the final release of GlassFish version 3.1. Whoever I'll give this combination a try and report back.
        Hide
        Sanjeeb Sahoo added a comment -

        I plan to do some experiment around using Gemini/JPA 1.0M3 in GF3.1 this week.
        The plan of record is to integrate EclipseLink 2.2 in GF 3.1. Gemini/JPA 1.0
        will sit on top of EclipseLink 2.2. I am in touch with all parties involved here
        which include EclipseLink team, Gemini/JPA Team and GlassFish/JPA team.

        Let me know what you observe as well.

        Show
        Sanjeeb Sahoo added a comment - I plan to do some experiment around using Gemini/JPA 1.0M3 in GF3.1 this week. The plan of record is to integrate EclipseLink 2.2 in GF 3.1. Gemini/JPA 1.0 will sit on top of EclipseLink 2.2. I am in touch with all parties involved here which include EclipseLink team, Gemini/JPA Team and GlassFish/JPA team. Let me know what you observe as well.
        Hide
        arungupta added a comment -

        adding myself to cc

        Show
        arungupta added a comment - adding myself to cc
        Hide
        chaoslayer added a comment -

        I've just tried the EJB approach and detached the initialization of the ODE server but I'm now faced with another problem (using b30):

        INFO: Bundle having id 279 is a JPA bundle
        INFO: Exploded bundle ode-axis2-bundle [279] at /tmp/osgiapp6704711471325654569
        INFO: Source = /tmp/osgiapp6704711471325654569, Target = /tmp/enhanced-osgiapp8718378730100273720
        INFO: Deleted /tmp/osgiapp6704711471325654569
        WARNING: Failed to enhance bundle having id 279
        Local Exception Stack:
        Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20101020-r8375): org.eclipse.persistence.exceptions.ValidationException
        Exception Description: The type [class java.lang.Long] for the attribute [id] on the entity class [class org.apache.ode.dao.jpa2.ProcessInstanceDAOImpl] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface.
        at org.eclipse.persistence.exceptions.ValidationException.invalidTypeForSerializedAttribute(ValidationException.java:1087)
        at org.eclipse.persistence.internal.jpa.metadata.converters.SerializedMetadata.process(SerializedMetadata.java:86)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processSerialized(MappingAccessor.java:1664)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processJPAConverters(MappingAccessor.java:1447)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingConverter(MappingAccessor.java:1509)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingValueConverter(MappingAccessor.java:1527)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.BasicAccessor.process(BasicAccessor.java:372)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.IdAccessor.process(IdAccessor.java:83)
        at org.eclipse.persistence.internal.jpa.metadata.MetadataDescriptor.processMappingAccessors(MetadataDescriptor.java:1412)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.processMappingAccessors(ClassAccessor.java:1405)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.processMappingAccessors(EntityAccessor.java:1061)
        at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.process(EntityAccessor.java:601)
        at org.eclipse.persistence.internal.jpa.metadata.MetadataProject.processStage2(MetadataProject.java:1464)
        at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.processORMMetadata(MetadataProcessor.java:474)
        at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:441)
        at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.buildTransformer(StaticWeaveClassTransformer.java:165)
        at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.buildClassTransformers(StaticWeaveClassTransformer.java:125)
        at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.<init>(StaticWeaveClassTransformer.java:82)
        at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveProcessor.process(StaticWeaveProcessor.java:250)
        at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveProcessor.performWeaving(StaticWeaveProcessor.java:174)
        at org.glassfish.osgijpa.EclipseLinkEnhancer.enhance(EclipseLinkEnhancer.java:131)
        at org.glassfish.osgijpa.EclipseLinkEnhancer.enhance(EclipseLinkEnhancer.java:99)
        at org.glassfish.osgijpa.JPABundleProcessor.enhance(JPABundleProcessor.java:142)
        at org.glassfish.osgijpa.JPAExtender.bundleChanged(JPAExtender.java:93)
        at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807)
        at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729)
        at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610)
        at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3710)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2628)
        at org.apache.felix.framework.Felix.installBundle(Felix.java:2424)
        at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:129)
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:953)
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:872)
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:785)
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:423)
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241)

        I always thought that weaving is only required in JavaSE environments e.g. for lazy loading and the like. Am I missing something here? So if the bundle already is managed by the container it shouldn't be necessary to invoke the static weaving processor.

        I also filed bug #331162 upstream (https://bugs.eclipse.org/bugs/show_bug.cgi?id=331162) but didn't get any response yet.

        In the meantime is it possible to "disable" JPA enhancement for a bundle?

        Show
        chaoslayer added a comment - I've just tried the EJB approach and detached the initialization of the ODE server but I'm now faced with another problem (using b30): INFO: Bundle having id 279 is a JPA bundle INFO: Exploded bundle ode-axis2-bundle [279] at /tmp/osgiapp6704711471325654569 INFO: Source = /tmp/osgiapp6704711471325654569, Target = /tmp/enhanced-osgiapp8718378730100273720 INFO: Deleted /tmp/osgiapp6704711471325654569 WARNING: Failed to enhance bundle having id 279 Local Exception Stack: Exception [EclipseLink-7155] (Eclipse Persistence Services - 2.2.0.v20101020-r8375): org.eclipse.persistence.exceptions.ValidationException Exception Description: The type [class java.lang.Long] for the attribute [id] on the entity class [class org.apache.ode.dao.jpa2.ProcessInstanceDAOImpl] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface. at org.eclipse.persistence.exceptions.ValidationException.invalidTypeForSerializedAttribute(ValidationException.java:1087) at org.eclipse.persistence.internal.jpa.metadata.converters.SerializedMetadata.process(SerializedMetadata.java:86) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processSerialized(MappingAccessor.java:1664) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processJPAConverters(MappingAccessor.java:1447) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingConverter(MappingAccessor.java:1509) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingValueConverter(MappingAccessor.java:1527) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.BasicAccessor.process(BasicAccessor.java:372) at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.IdAccessor.process(IdAccessor.java:83) at org.eclipse.persistence.internal.jpa.metadata.MetadataDescriptor.processMappingAccessors(MetadataDescriptor.java:1412) at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.processMappingAccessors(ClassAccessor.java:1405) at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.processMappingAccessors(EntityAccessor.java:1061) at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.process(EntityAccessor.java:601) at org.eclipse.persistence.internal.jpa.metadata.MetadataProject.processStage2(MetadataProject.java:1464) at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.processORMMetadata(MetadataProcessor.java:474) at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.processORMetadata(PersistenceUnitProcessor.java:441) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.buildTransformer(StaticWeaveClassTransformer.java:165) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.buildClassTransformers(StaticWeaveClassTransformer.java:125) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveClassTransformer.<init>(StaticWeaveClassTransformer.java:82) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveProcessor.process(StaticWeaveProcessor.java:250) at org.eclipse.persistence.tools.weaving.jpa.StaticWeaveProcessor.performWeaving(StaticWeaveProcessor.java:174) at org.glassfish.osgijpa.EclipseLinkEnhancer.enhance(EclipseLinkEnhancer.java:131) at org.glassfish.osgijpa.EclipseLinkEnhancer.enhance(EclipseLinkEnhancer.java:99) at org.glassfish.osgijpa.JPABundleProcessor.enhance(JPABundleProcessor.java:142) at org.glassfish.osgijpa.JPAExtender.bundleChanged(JPAExtender.java:93) at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:807) at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:729) at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:610) at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:3710) at org.apache.felix.framework.Felix.installBundle(Felix.java:2628) at org.apache.felix.framework.Felix.installBundle(Felix.java:2424) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:129) at org.apache.felix.fileinstall.internal.DirectoryWatcher.installOrUpdateBundle(DirectoryWatcher.java:953) at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:872) at org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:785) at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:423) at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:241) I always thought that weaving is only required in JavaSE environments e.g. for lazy loading and the like. Am I missing something here? So if the bundle already is managed by the container it shouldn't be necessary to invoke the static weaving processor. I also filed bug #331162 upstream ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=331162 ) but didn't get any response yet. In the meantime is it possible to "disable" JPA enhancement for a bundle?
        Hide
        Sanjeeb Sahoo added a comment -

        When you use EclipseLink from an OSGi bundle, the bundle class loader is not exactly in the control of eclipselink or appserver, so eclipselink relies on some Equinox extension to do weaving (aka enhancement) which obviously does not work on other OSGi runtime. So, we have built a special feature in GlassFish where we enhance the entity classes when the persistence bundle gets installed. This is done by osgi-jpa.jar bundle. The beauty of this solution is that it only happens once as it is done at bundle installation time. We uses EclipseLink static weaver to achieve this. Hope this explains why you see StaticWeavProcessor in stack trace. You can disable this feature by adding the following header in your bundle:
        GlassFish-StaticallyWeaved = true

        Having said that, even if your bundle failed to weave, it should continue to get activated though. In other words, it is done on an best effort basis. Are you seeing a different behavior?

        Finally, the error from enhancer is slightly strange, because I think Long need not be serializable - or may be I have started to forget JPA now.

        BTW, I am about to fix the original issue reported in this forum which is to allow users to call Persistence class from bundle's activator.

        Sahoo

        Show
        Sanjeeb Sahoo added a comment - When you use EclipseLink from an OSGi bundle, the bundle class loader is not exactly in the control of eclipselink or appserver, so eclipselink relies on some Equinox extension to do weaving (aka enhancement) which obviously does not work on other OSGi runtime. So, we have built a special feature in GlassFish where we enhance the entity classes when the persistence bundle gets installed. This is done by osgi-jpa.jar bundle. The beauty of this solution is that it only happens once as it is done at bundle installation time. We uses EclipseLink static weaver to achieve this. Hope this explains why you see StaticWeavProcessor in stack trace. You can disable this feature by adding the following header in your bundle: GlassFish-StaticallyWeaved = true Having said that, even if your bundle failed to weave, it should continue to get activated though. In other words, it is done on an best effort basis. Are you seeing a different behavior? Finally, the error from enhancer is slightly strange, because I think Long need not be serializable - or may be I have started to forget JPA now. BTW, I am about to fix the original issue reported in this forum which is to allow users to call Persistence class from bundle's activator. Sahoo
        Hide
        chaoslayer added a comment -

        Thanks a lot, the suggested Manifest Header "GlassFish-StaticallyWeaved: true" helped indeed.

        I tried to overcome the initial Persistence problem by setting a TCCL manually directly around the invocations but it didn't help. So I'm glad that you're fixing this.

        Show
        chaoslayer added a comment - Thanks a lot, the suggested Manifest Header "GlassFish-StaticallyWeaved: true" helped indeed. I tried to overcome the initial Persistence problem by setting a TCCL manually directly around the invocations but it didn't help. So I'm glad that you're fixing this.
        Hide
        chaoslayer added a comment -

        Please also take a look at issue GLASSFISH-14840 (http://java.net/jira/browse/GLASSFISH-14840) as I'm currently trying hard to get a workaround until a fix for this is available.

        The application (ODE) strictly relies on the possibility to manually create EntityManager instances from some available EntityManagerFactory as it does all the transaction handling by itself.

        So if I configure a persistence unit for JTA in persistence.xml I get EntityManagerFactoryWrapper instances injected into my wrapper beans but calling createEntityManager() is (and this is spec conform) not supported as it is not backed by a real EntityManagerFactory.

        If I configure RESOURCE_LOCAL I'm getting the exception mentioned in that issue. So I'm completely stuck here.

        Show
        chaoslayer added a comment - Please also take a look at issue GLASSFISH-14840 ( http://java.net/jira/browse/GLASSFISH-14840 ) as I'm currently trying hard to get a workaround until a fix for this is available. The application (ODE) strictly relies on the possibility to manually create EntityManager instances from some available EntityManagerFactory as it does all the transaction handling by itself. So if I configure a persistence unit for JTA in persistence.xml I get EntityManagerFactoryWrapper instances injected into my wrapper beans but calling createEntityManager() is (and this is spec conform) not supported as it is not backed by a real EntityManagerFactory. If I configure RESOURCE_LOCAL I'm getting the exception mentioned in that issue. So I'm completely stuck here.
        Hide
        Sanjeeb Sahoo added a comment -

        I am in the process of addressing the original issue that prohibits users to invoke Persistence.createEntityManagerFactory from an OSGi bundle's activator. It does not currently work because Persistence class relies on Thread's context class loader to
        a) locate persistence.xml files that user wants to use,
        b) locate persistence providers that user wants to use.

        While the first one can be addressed by user by temorarily setting context class loader to own bundle's class loader, the second one is difficult to fix unless one also changes their bundle to have a hard dependency on persistence provider bundle. A better way to address the second point is to make use of javax.persistence.spi.PersistenceProviderResolver and javax.persistence.spi.PersistenceProviderResolverHolder interfaces that's introduced JPA 2.0 spec. I am attaching a test case and patch to this effect.

        To test, do the following:

        asadmin start-database
        asadmin start
        asadmin deploy --type=osgi entities1-osgi.jar
        or
        cp entities1-osgi.jar to domain1/autodeploy/bundles/
        or install and start using shell or some other means.

        First try without patch and then with the patch to see the effect of the patch. The patch does not really take effect unless either a system property or osgi property called org.glassfish.persistence.jpa.UseOSGiPersistenceProviderResolver defined to be true.

        Show
        Sanjeeb Sahoo added a comment - I am in the process of addressing the original issue that prohibits users to invoke Persistence.createEntityManagerFactory from an OSGi bundle's activator. It does not currently work because Persistence class relies on Thread's context class loader to a) locate persistence.xml files that user wants to use, b) locate persistence providers that user wants to use. While the first one can be addressed by user by temorarily setting context class loader to own bundle's class loader, the second one is difficult to fix unless one also changes their bundle to have a hard dependency on persistence provider bundle. A better way to address the second point is to make use of javax.persistence.spi.PersistenceProviderResolver and javax.persistence.spi.PersistenceProviderResolverHolder interfaces that's introduced JPA 2.0 spec. I am attaching a test case and patch to this effect. To test, do the following: asadmin start-database asadmin start asadmin deploy --type=osgi entities1-osgi.jar or cp entities1-osgi.jar to domain1/autodeploy/bundles/ or install and start using shell or some other means. First try without patch and then with the patch to see the effect of the patch. The patch does not really take effect unless either a system property or osgi property called org.glassfish.persistence.jpa.UseOSGiPersistenceProviderResolver defined to be true.
        Hide
        chaoslayer added a comment -

        I've patched the jpa-connector accordingly and well, what should I say now...

        THANX SO MUCH!

        It finally works!

        Show
        chaoslayer added a comment - I've patched the jpa-connector accordingly and well, what should I say now... THANX SO MUCH! It finally works!
        Hide
        Sanjeeb Sahoo added a comment -

        After receiving the comment from Mitesh, I have decided to place my changes in a new module as opposed to jpa-connector module. So, I am attaching changes2.zip which now introduces a new module called osgi-jpa-javase, which will be distributed as part of the distribution and made available in modules/ dir, but won't have any effect until someone changes the osgi config file (e.g., felix/conf/config.properties) to set org.glassfish.osgjpa.javase.useHybridPersistenceProviderResolver=true. This property is by default set to false.

        If anyone has applied the old patch, they need to roll it back.

        I am still going through review comments, so I will check-in after it is done.

        Show
        Sanjeeb Sahoo added a comment - After receiving the comment from Mitesh, I have decided to place my changes in a new module as opposed to jpa-connector module. So, I am attaching changes2.zip which now introduces a new module called osgi-jpa-javase, which will be distributed as part of the distribution and made available in modules/ dir, but won't have any effect until someone changes the osgi config file (e.g., felix/conf/config.properties) to set org.glassfish.osgjpa.javase.useHybridPersistenceProviderResolver=true. This property is by default set to false. If anyone has applied the old patch, they need to roll it back. I am still going through review comments, so I will check-in after it is done.
        Hide
        chaoslayer added a comment -

        Are there no integration tests that cover JPA deployments?

        I would think that a project like glassfish should have thousands of test cases that are run before each of the promoted builds.

        However do you expect any negative side effects of this JPA resolver method? I mean in my case the situation would that I want to use this method for initialization of ODE (JavaSE mode resolver) but I will definitely have a lot of other OSGi bundles that use standard JavaEE injection techniques to get their Entitymanager inside various SLSBs.

        Show
        chaoslayer added a comment - Are there no integration tests that cover JPA deployments? I would think that a project like glassfish should have thousands of test cases that are run before each of the promoted builds. However do you expect any negative side effects of this JPA resolver method? I mean in my case the situation would that I want to use this method for initialization of ODE (JavaSE mode resolver) but I will definitely have a lot of other OSGi bundles that use standard JavaEE injection techniques to get their Entitymanager inside various SLSBs.
        Hide
        Sanjeeb Sahoo added a comment -

        There are plenty of tests in GlassFish that test JPA deployment.

        No, I don't expect any negative effect of the new resolver. I have tried it in normal EE apps as well. In fact, it fixes a couple of nasty bugs in the default resolver that's defined in the reference implementation. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=331094 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=331098. The new resolver I wrote does not have such bugs at least.

        Show
        Sanjeeb Sahoo added a comment - There are plenty of tests in GlassFish that test JPA deployment. No, I don't expect any negative effect of the new resolver. I have tried it in normal EE apps as well. In fact, it fixes a couple of nasty bugs in the default resolver that's defined in the reference implementation. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=331094 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=331098 . The new resolver I wrote does not have such bugs at least.
        Hide
        chaoslayer added a comment -

        Perfect.

        Once again thanks a lot for this!

        Show
        chaoslayer added a comment - Perfect. Once again thanks a lot for this!
        Hide
        Sanjeeb Sahoo added a comment -

        Just committed:

        Please note the name change once again. It is now called osgi-jpa-extension. The property names have also been changed. So, if you have applied earlier attached patches, roll them back, get a new glassfish build and set the following property to true in felix or equinox config file ( the property is set to false by default, as this is an extension):

        org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true

        ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -F msg osgi-javaee/ packager/glassfish-jpa/ osgi-platforms/
        Adding osgi-javaee/osgi-jpa-extension
        Adding osgi-javaee/osgi-jpa-extension/osgi.bundle
        Adding osgi-javaee/osgi-jpa-extension/pom.xml
        Adding osgi-javaee/osgi-jpa-extension/src
        Adding osgi-javaee/osgi-jpa-extension/src/main
        Adding osgi-javaee/osgi-jpa-extension/src/main/java
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension/HybridPersistenceProviderResolver.java
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension/JPAStartupService.java
        Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension/OSGiJPAExtnBundleActivator.java
        Sending osgi-javaee/pom.xml
        Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini
        Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties
        Sending packager/glassfish-jpa/pom.xml
        Transmitting file data .........
        Committed revision 43268.

        Show
        Sanjeeb Sahoo added a comment - Just committed: Please note the name change once again. It is now called osgi-jpa-extension. The property names have also been changed. So, if you have applied earlier attached patches, roll them back, get a new glassfish build and set the following property to true in felix or equinox config file ( the property is set to false by default, as this is an extension): org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -F msg osgi-javaee/ packager/glassfish-jpa/ osgi-platforms/ Adding osgi-javaee/osgi-jpa-extension Adding osgi-javaee/osgi-jpa-extension/osgi.bundle Adding osgi-javaee/osgi-jpa-extension/pom.xml Adding osgi-javaee/osgi-jpa-extension/src Adding osgi-javaee/osgi-jpa-extension/src/main Adding osgi-javaee/osgi-jpa-extension/src/main/java Adding osgi-javaee/osgi-jpa-extension/src/main/java/org Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension/HybridPersistenceProviderResolver.java Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension/JPAStartupService.java Adding osgi-javaee/osgi-jpa-extension/src/main/java/org/glassfish/osgijpa/extension/OSGiJPAExtnBundleActivator.java Sending osgi-javaee/pom.xml Sending osgi-platforms/equinox/src/main/resources/glassfish/osgi/equinox/configuration/config.ini Sending osgi-platforms/felix/src/main/resources/glassfish/osgi/felix/conf/config.properties Sending packager/glassfish-jpa/pom.xml Transmitting file data ......... Committed revision 43268.
        Hide
        Sanjeeb Sahoo added a comment -

        Updated the synopsys

        Show
        Sanjeeb Sahoo added a comment - Updated the synopsys

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            chaoslayer
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: