-
Bug
-
Resolution: Done
-
Major
-
jboss-fuse-6.1
A basic Hibernate JPA example containing 4 bundles:
1) Datasource - datasource in blueprint - exports as a service
2) Datamodel - entity classes and persistence.xml
3) Feature - feature.xml file
4) JAX RS Webservice - Web service + persistence layer - blueprint bean jpa:context for entity manager
In Fabric, the deployment agent can not correctly correlate and manage the relationship between the exported service reference to the datasource and the lookup of that service in the persistence.xml, even when they are in separate bundles. This results in the deployment order falling back to using a sorted list. In this case, if your datasource bundle is alphabetically after the persistence.xml bundle, it leads to the bundle referencing the persistence unit to go into an unrecoverable GracePeriod and the persistence unit never being created.
If you only delete the persistence unit bundle from the cache directory between the stop and start, then starting up the container works correctly (when you use the reference).
This leads me to believe something is being cached or not shutdown correctly in the stop / start scenario.
2015-11-12 18:47:06,613 | WARN | agent-1-thread-1 | container | impl.EntityManagerFactoryManager 366 | 1224 - org.apache.aries.jpa.container - 1.0.1.redhat-611452 | Error creating EntityManagerFactory java.lang.RuntimeException: The DataSource osgi:service/jdbc/Hibernate_XADS required by bundle datamodel/1.0.0.SNAPSHOT could not be found. at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(JndiDataSource.java:86)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] at org.apache.aries.jpa.container.unit.impl.DelayedLookupDataSource.getConnection(DelayedLookupDataSource.java:38)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:70)[1262:org.hibernate.entitymanager:4.2.9.Final] at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$ConnectionProviderJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:242)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:117)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:76)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:158)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:130)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1825)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1783)[1261:org.hibernate.core:4.2.9.Final] at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:96)[1262:org.hibernate.entitymanager:4.2.9.Final] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:914)[1262:org.hibernate.entitymanager:4.2.9.Final] at org.hibernate.osgi.OsgiPersistenceProvider.createContainerEntityManagerFactory(OsgiPersistenceProvider.java:99)[1263:org.hibernate.osgi:4.2.9.Final] at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.createEntityManagerFactories(EntityManagerFactoryManager.java:362)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.registerEntityManagerFactories(EntityManagerFactoryManager.java:274)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] at org.apache.aries.jpa.container.impl.EntityManagerFactoryManager.bundleStateChange(EntityManagerFactoryManager.java:216)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] at org.apache.aries.jpa.container.impl.PersistenceBundleManager.modifiedBundle(PersistenceBundleManager.java:296)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)[10:org.apache.aries.util:1.0.1.redhat-611423] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)[10:org.apache.aries.util:1.0.1.redhat-611423] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)[10:org.apache.aries.util:1.0.1.redhat-611423] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)[10:org.apache.aries.util:1.0.1.redhat-611423] at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)[10:org.apache.aries.util:1.0.1.redhat-611423] at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:696)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:484)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4650)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.Felix$4.run(Felix.java:2123)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.Felix.runInContext(Felix.java:2147)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.Felix.startBundle(Felix.java:2121)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] at io.fabric8.agent.DeploymentAgent.install(DeploymentAgent.java:955)[58:io.fabric8.fabric-agent:1.0.0.redhat-424] at io.fabric8.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:572)[58:io.fabric8.fabric-agent:1.0.0.redhat-424] at io.fabric8.agent.DeploymentAgent$2.run(DeploymentAgent.java:293)[58:io.fabric8.fabric-agent:1.0.0.redhat-424] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_60] at java.util.concurrent.FutureTask.run(FutureTask.java:262)[:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_60] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_60] at java.lang.Thread.run(Thread.java:745)[:1.7.0_60] Caused by: javax.naming.NameNotFoundException: osgi:service/jdbc/Hibernate_XADS at org.apache.aries.jndi.url.ServiceRegistryContext.lookup(ServiceRegistryContext.java:113)[1220:org.apache.aries.jndi.url:1.0.0] at org.apache.aries.jndi.url.ServiceRegistryContext.lookup(ServiceRegistryContext.java:144)[1220:org.apache.aries.jndi.url:1.0.0] at org.apache.aries.jndi.DelegateContext.lookup(DelegateContext.java:161)[1217:org.apache.aries.jndi.core:1.0.0] at javax.naming.InitialContext.lookup(InitialContext.java:411)[:1.7.0_60] at org.apache.aries.jpa.container.unit.impl.JndiDataSource.getDs(JndiDataSource.java:65)[1224:org.apache.aries.jpa.container:1.0.1.redhat-611452] ... 38 more
Even with a mandatory relationship through a reference (which isn't required for this use case), the bundle only appears to correct wait on deployment to a running container. It does not appear to enforce the bundles to correctly wait when stopping and restarting. The datamodel and datasource bundles end up in active+created states, but the entitymanagerfactory is actually never created by the bundle. The persistence layer ends up in GracePeriod due to the entity manager factory.
<reference id="dataSource" interface="javax.sql.DataSource" filter="(datasource.name=NonXA_DS)" availability="mandatory"/>
I see 2 parts to the problem:
1) The dependencies are not being 100% respected in fabric (standalone mode can control them with bundle start levels)
2) If the persistence.xml bundle transitions to ACTIVE state, the creation of the persistence unit is never attempted even if the dependency becomes available. Aries only tries twice to create the PU, at bundle resolved and bundle active.
While things are in GracePeriod and the datasource is created, a restart of the persistence unit bundle resolves all of the issues and the service starts working.
A hackish approach using a BundleActivator to force start the datasource bundle also appears to work for the use cases I tested.
- is related to
-
ARIES-840 Loading...