Hi all, I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 to use a preview of Hibernate ORM version 5. It seems the JPA deployer isn't allowing me to run such experiments: # First experiment - providerModule set to custom module In my first attempt, I create a custom set of jboss modules which include the snapshot builds of ORM 5, add them to my standalone WF9 instance and set the persistence.xml property: jboss.as.jpa.providerModule = my-custom-module-name and then get: Caused by: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.boot.internal.EnversIntegrator not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) [rt.jar:1.7.0_51] at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) ... 7 more Clearly it looks like I'm being served classes from the bundled Hibernate 4.x implementation - on top of those from the module I'm requesting. This isn't what the deployer should be doing, right? # Second experiment - use the "application provided" In this case I hope to hint the JPA deployer to not add the default implementor but look for a JPA implementation within my deployment, but still package my custom Hibernate build as a module. - use the same custom module containing Hibernate ORM 5 (a preview snapshot) - Add a "Dependency:" section to the manifest to import (and export) my custom module - set the "jboss.as.jpa.providerModule" property to value "application" This gets me: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYJPA0027: Persistence provider module load error application (class org.hibernate.jpa.HibernatePersistenceProvider) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] ... 5 more Caused by: org.jboss.modules.ModuleNotFoundException: application:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) [jboss-modules.jar:1.4.3.Final] at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) ... 10 more Remarks: - it's attempting to load the "application:main" module?! that's not what I'd expect from reading [1]

- the provider should be available to the deployment classpath, so I'm not sure why it's not finding the Provider? (I'm even exporting it, although I'm not sure if that was required).

Any suggestions to get this running please? Also I wonder if some of these should warrant opening a JIRA, but I'm not sure how far I misunderstood the intentions of these JPA deployer properties.

Thanks, Sanne [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere...

Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course.

It would help speed up the Hibernate 5 stream adoption and avoid a lot of duplicated work for 6+ months. > On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon > for WildFly 10. > >> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> Hi all, >> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >> to use a preview of Hibernate ORM version 5. >> >> It seems the JPA deployer isn't allowing me to run such experiments: >> >> # First experiment - providerModule set to custom module >> >> In my first attempt, I create a custom set of jboss modules which >> include the snapshot builds of ORM 5, add them to my standalone WF9 >> instance and set the persistence.xml property: >> jboss.as.jpa.providerModule = my-custom-module-name >> >> and then get: >> >> Caused by: java.util.ServiceConfigurationError: >> org.hibernate.integrator.spi.Integrator: Provider >> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] >> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] >> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> [rt.jar:1.7.0_51] >> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] >> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >> at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> ... 7 more >> >> Clearly it looks like I'm being served classes from the bundled >> Hibernate 4.x implementation - on top of those from the module I'm >> requesting. This isn't what the deployer should be doing, right? >> >> # Second experiment - use the "application provided" >> >> In this case I hope to hint the JPA deployer to not add the default >> implementor but look for a JPA implementation within my deployment, >> but still package my custom Hibernate build as a module. >> >> - use the same custom module containing Hibernate ORM 5 (a preview snapshot) >> - Add a "Dependency:" section to the manifest to import (and export) >> my custom module >> - set the "jboss.as.jpa.providerModule" property to value "application" >> >> This gets me: >> >> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> WFLYJPA0027: Persistence provider module load error application (class >> org.hibernate.jpa.HibernatePersistenceProvider) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> ... 5 more >> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> [jboss-modules.jar:1.4.3.Final] >> at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> ... 10 more >> >> Remarks: >> - it's attempting to load the "application:main" module?! that's not >> what I'd expect from reading [1] > > This seems to be a bug. I hit it a few days ago when I packaged > Hibernate ORM 4.1.x with an application (in a unit test) and forgot to > set the persistence provider in persistence.xml. > >> - the provider should be available to the deployment classpath, so >> I'm not sure why it's not finding the Provider? (I'm even exporting >> it, although I'm not sure if that was required). > > Providers are always found through the > javax.persistence.spi.PersistenceProviderResolver, not directly from the > deployment classpath. > >> >> Any suggestions to get this running please? >> >> Also I wonder if some of these should warrant opening a JIRA, but I'm >> not sure how far I misunderstood the intentions of these JPA deployer >> properties. > > Lets talk in a few days again on IRC. > >> >> Thanks, >> Sanne >> >> [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev

Scott, if you do one last jipijapa release that adds "support" for hibernate5 hibernate guys could take that version and override it in wildfly 9 same way as they add new h5 modules.

-- tomaz On Thu, May 21, 2015 at 9:01 PM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the integration code that we will look at merging into WildFly 10. Are you looking for a custom WildFly 9.x branch or actual changes in WildFly 9 (doesn't seem as likely to me but I don't control the schedule)? > > It would help speed up the Hibernate 5 stream adoption and avoid a lot of duplicated work for 6+ months. > >> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: >> >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on this soon >> for WildFly 10. >> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>> Hi all, >>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >>> to use a preview of Hibernate ORM version 5. >>> >>> It seems the JPA deployer isn't allowing me to run such experiments: >>> >>> # First experiment - providerModule set to custom module >>> >>> In my first attempt, I create a custom set of jboss modules which >>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>> instance and set the persistence.xml property: >>> jboss.as.jpa.providerModule = my-custom-module-name >>> >>> and then get: >>> >>> Caused by: java.util.ServiceConfigurationError: >>> org.hibernate.integrator.spi.Integrator: Provider >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] >>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>> [rt.jar:1.7.0_51] >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] >>> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>> at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >>> at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >>> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >>> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>> at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >>> at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>> at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>> ... 7 more >>> >>> Clearly it looks like I'm being served classes from the bundled >>> Hibernate 4.x implementation - on top of those from the module I'm >>> requesting. This isn't what the deployer should be doing, right? >>> >>> # Second experiment - use the "application provided" >>> >>> In this case I hope to hint the JPA deployer to not add the default >>> implementor but look for a JPA implementation within my deployment, >>> but still package my custom Hibernate build as a module. >>> >>> - use the same custom module containing Hibernate ORM 5 (a preview snapshot) >>> - Add a "Dependency:" section to the manifest to import (and export) >>> my custom module >>> - set the "jboss.as.jpa.providerModule" property to value "application" >>> >>> This gets me: >>> >>> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>> WFLYJPA0027: Persistence provider module load error application (class >>> org.hibernate.jpa.HibernatePersistenceProvider) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>> ... 5 more >>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>> [jboss-modules.jar:1.4.3.Final] >>> at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>> ... 10 more >>> >>> Remarks: >>> - it's attempting to load the "application:main" module?! that's not >>> what I'd expect from reading [1] >> >> This seems to be a bug. I hit it a few days ago when I packaged >> Hibernate ORM 4.1.x with an application (in a unit test) and forgot to >> set the persistence provider in persistence.xml. >> >>> - the provider should be available to the deployment classpath, so >>> I'm not sure why it's not finding the Provider? (I'm even exporting >>> it, although I'm not sure if that was required). >> >> Providers are always found through the >> javax.persistence.spi.PersistenceProviderResolver, not directly from the >> deployment classpath. >> >>> >>> Any suggestions to get this running please? >>> >>> Also I wonder if some of these should warrant opening a JIRA, but I'm >>> not sure how far I misunderstood the intentions of these JPA deployer >>> properties. >> >> Lets talk in a few days again on IRC. >> >>> >>> Thanks, >>> Sanne >>> >>> [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev

On May 28, 2015, at 5:30 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: Could someone explain please, why it's hard to have a deployer just use a different JPA implementor which the user might want to provide? I'm pretty sure I know how to start a JPA context in plain JavaSE, and don't need to know which implementor version I'm going to use, other than for sake of configuration. The WildFly documentation mentions this property "jboss.as.jpa.providerModule", which sounds great on paper and it would be a nice usability improvement if it would also actually work as it suggests. There's plenty of evidence on StackOverflow that the current limitations are unexpected. For example, Spring moved to Hibernate 5 and people won't be able to use your stable line of the application server with Spring; I'd hope we could implement a plan to prevent this from happening at the next upgrade cycles. Thanks, Sanne On 21 May 2015 at 20:10, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > > On 05/21/2015 03:05 PM, Tomaž Cerar wrote: >> Scott, >> >> if you do one last jipijapa release that adds "support" for hibernate5 >> hibernate guys could take that version and override it in wildfly 9 same >> way as they add new h5 modules. > > I assume this will be an iterative process but sure, we could also push > a release of the JIPI-31 branch. Lets keep talking about what is needed... > >> >> -- >> tomaz >> >> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow <smarlow(a)redhat.com >> <mailto:smarlow@redhat.com>> wrote: >> >> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >> >> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >> integration code that we will look at merging into WildFly 10. Are you >> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >> (doesn't seem as likely to me but I don't control the schedule)? >> >>> >>> It would help speed up the Hibernate 5 stream adoption and avoid >> a lot of duplicated work for 6+ months. >>> >>>> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com >> <mailto:smarlow@redhat.com>> wrote: >>>> >>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >> this soon >>>> for WildFly 10. >>>> >>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>> Hi all, >>>>> I'm attempting to deploy some integration tests on WildFly >> 9.0.0.CR1 >>>>> to use a preview of Hibernate ORM version 5. >>>>> >>>>> It seems the JPA deployer isn't allowing me to run such >> experiments: >>>>> >>>>> # First experiment - providerModule set to custom module >>>>> >>>>> In my first attempt, I create a custom set of jboss modules which >>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>>> instance and set the persistence.xml property: >>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>> >>>>> and then get: >>>>> >>>>> Caused by: java.util.ServiceConfigurationError: >>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >> [rt.jar:1.7.0_51] >>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >> [rt.jar:1.7.0_51] >>>>> at >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>> [rt.jar:1.7.0_51] >>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >> [rt.jar:1.7.0_51] >>>>> at >> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>> at >> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >>>>> at >> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >>>>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >>>>> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>> at >> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >>>>> at >> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>> ... 7 more >>>>> >>>>> Clearly it looks like I'm being served classes from the bundled >>>>> Hibernate 4.x implementation - on top of those from the module I'm >>>>> requesting. This isn't what the deployer should be doing, right? >>>>> >>>>> # Second experiment - use the "application provided" >>>>> >>>>> In this case I hope to hint the JPA deployer to not add the >> default >>>>> implementor but look for a JPA implementation within my deployment, >>>>> but still package my custom Hibernate build as a module. >>>>> >>>>> - use the same custom module containing Hibernate ORM 5 (a >> preview snapshot) >>>>> - Add a "Dependency:" section to the manifest to import (and >> export) >>>>> my custom module >>>>> - set the "jboss.as.jpa.providerModule" property to value >> "application" >>>>> >>>>> This gets me: >>>>> >>>>> Caused by: >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>> WFLYJPA0027: Persistence provider module load error application >> (class >>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>> at >> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>> at >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>> ... 5 more >>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >> application:main >>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>> [jboss-modules.jar:1.4.3.Final] >>>>> at >> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>> ... 10 more >>>>> >>>>> Remarks: >>>>> - it's attempting to load the "application:main" module?! >> that's not >>>>> what I'd expect from reading [1] >>>> >>>> This seems to be a bug. I hit it a few days ago when I packaged >>>> Hibernate ORM 4.1.x with an application (in a unit test) and >> forgot to >>>> set the persistence provider in persistence.xml. >>>> >>>>> - the provider should be available to the deployment >> classpath, so >>>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>>> it, although I'm not sure if that was required). >>>> >>>> Providers are always found through the >>>> javax.persistence.spi.PersistenceProviderResolver, not directly >> from the >>>> deployment classpath. >>>> >>>>> >>>>> Any suggestions to get this running please? >>>>> >>>>> Also I wonder if some of these should warrant opening a JIRA, >> but I'm >>>>> not sure how far I misunderstood the intentions of these JPA >> deployer >>>>> properties. >>>> >>>> Lets talk in a few days again on IRC. >>>> >>>>> >>>>> Thanks, >>>>> Sanne >>>>> >>>>> [1] - >> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On May 28, 2015, at 9:29 AM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: I am just not sure a lot of this is true. What EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA bootstrap SPI) contracts changed in 5.0? As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, but we currently do not use it. So that actually should also not cause any issues in regards to Hibernate 4.x or 5.0 As far as using the standard JPA bootstrap SPIs, I agree this is up to Scott. But it simply will not work for the way WildFly does stuff as I understand it. Second-level cache, yes, is a whole other ball of wax :) On Thu, May 28, 2015 at 9:18 AM, Jason Greene <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: We implement the standard JPA integration SPI, but it is absolutely awful. It forces: - The construction of duplicate class loaders with duplicate class definitions of every class in the deployment - Repeated runs of the deployment process - Double loading of any class related to JPA (and its dependencies) - The JPA provider to use reflection for all annotation discovery - Double use of reflection in the deployment process - Bugs from chicken and egg problems - Increased memory usage So for this reason WildFly and Hibernate have their own integration SPIs, and those SPIs are changing in hibernate 5. So WildFly (well currently JIPPAJAPPA) needs an update to be compatible with them. Additionally we have the Jandex 2 change which is pending that both projects are attempting to align on. Now what I am not sure about, Scott will have to answer this. Is if you can use the standard JPA integration SPI with newer versions of Hibernate and just live with the nastiness it brings. However, there is still a secondary issue, which I am sure you already know about is that the second level cache and hibernate search have integrations that need to be compatible and in sync and tested. > On May 28, 2015, at 5:30 AM, Sanne Grinovero <sanne(a)hibernate.org <mailto:sanne@hibernate.org>> wrote: > > Could someone explain please, why it's hard to have a deployer just > use a different JPA implementor which the user might want to provide? > > I'm pretty sure I know how to start a JPA context in plain JavaSE, and > don't need to know which implementor version I'm going to use, other > than for sake of configuration. > > The WildFly documentation mentions this property > "jboss.as.jpa.providerModule", which sounds great on paper and it > would be a nice usability improvement if it would also actually work > as it suggests. > > There's plenty of evidence on StackOverflow that the current > limitations are unexpected. For example, Spring moved to Hibernate 5 > and people won't be able to use your stable line of the application > server with Spring; I'd hope we could implement a plan to prevent this > from happening at the next upgrade cycles. > > Thanks, > Sanne > > On 21 May 2015 at 20:10, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: >> >> >> On 05/21/2015 03:05 PM, Tomaž Cerar wrote: >>> Scott, >>> >>> if you do one last jipijapa release that adds "support" for hibernate5 >>> hibernate guys could take that version and override it in wildfly 9 same >>> way as they add new h5 modules. >> >> I assume this will be an iterative process but sure, we could also push >> a release of the JIPI-31 branch. Lets keep talking about what is needed... >> >>> >>> -- >>> tomaz >>> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: >>> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>>> Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >>> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 <https://github.com/scottmarlow/jipijapa/tree/JIPI-31> contains the >>> integration code that we will look at merging into WildFly 10. Are you >>> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >>> (doesn't seem as likely to me but I don't control the schedule)? >>> >>>> >>>> It would help speed up the Hibernate 5 stream adoption and avoid >>> a lot of duplicated work for 6+ months. >>>> >>>>> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: >>>>> >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>> this soon >>>>> for WildFly 10. >>>>> >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>>> Hi all, >>>>>> I'm attempting to deploy some integration tests on WildFly >>> 9.0.0.CR1 >>>>>> to use a preview of Hibernate ORM version 5. >>>>>> >>>>>> It seems the JPA deployer isn't allowing me to run such >>> experiments: >>>>>> >>>>>> # First experiment - providerModule set to custom module >>>>>> >>>>>> In my first attempt, I create a custom set of jboss modules which >>>>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>>>> instance and set the persistence.xml property: >>>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>>> >>>>>> and then get: >>>>>> >>>>>> Caused by: java.util.ServiceConfigurationError: >>>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>> [rt.jar:1.7.0_51] >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>> [rt.jar:1.7.0_51] >>>>>> at >>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>>> [rt.jar:1.7.0_51] >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>> [rt.jar:1.7.0_51] >>>>>> at >>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>>> at >>> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >>>>>> at >>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >>>>>> at >>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >>>>>> at >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>>> at >>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>>> at >>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >>>>>> at >>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>>> at >>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>>> ... 7 more >>>>>> >>>>>> Clearly it looks like I'm being served classes from the bundled >>>>>> Hibernate 4.x implementation - on top of those from the module I'm >>>>>> requesting. This isn't what the deployer should be doing, right? >>>>>> >>>>>> # Second experiment - use the "application provided" >>>>>> >>>>>> In this case I hope to hint the JPA deployer to not add the >>> default >>>>>> implementor but look for a JPA implementation within my deployment, >>>>>> but still package my custom Hibernate build as a module. >>>>>> >>>>>> - use the same custom module containing Hibernate ORM 5 (a >>> preview snapshot) >>>>>> - Add a "Dependency:" section to the manifest to import (and >>> export) >>>>>> my custom module >>>>>> - set the "jboss.as.jpa.providerModule" property to value >>> "application" >>>>>> >>>>>> This gets me: >>>>>> >>>>>> Caused by: >>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>>> WFLYJPA0027: Persistence provider module load error application >>> (class >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>>> at >>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>>> ... 5 more >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >>> application:main >>>>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>>> [jboss-modules.jar:1.4.3.Final] >>>>>> at >>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>>> at >>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>>> ... 10 more >>>>>> >>>>>> Remarks: >>>>>> - it's attempting to load the "application:main" module?! >>> that's not >>>>>> what I'd expect from reading [1] >>>>> >>>>> This seems to be a bug. I hit it a few days ago when I packaged >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >>> forgot to >>>>> set the persistence provider in persistence.xml. >>>>> >>>>>> - the provider should be available to the deployment >>> classpath, so >>>>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>>>> it, although I'm not sure if that was required). >>>>> >>>>> Providers are always found through the >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >>> from the >>>>> deployment classpath. >>>>> >>>>>> >>>>>> Any suggestions to get this running please? >>>>>> >>>>>> Also I wonder if some of these should warrant opening a JIRA, >>> but I'm >>>>>> not sure how far I misunderstood the intentions of these JPA >>> deployer >>>>>> properties. >>>>> >>>>> Lets talk in a few days again on IRC. >>>>> >>>>>> >>>>>> Thanks, >>>>>> Sanne >>>>>> >>>>>> [1] - >>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... <https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev> >>> >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev> -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/wildfly-dev <https://lists.jboss.org/mailman/listinfo/wildfly-dev>

On May 28, 2015, at 10:42 AM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: On 05/28/2015 10:29 AM, Steve Ebersole wrote: > I am just not sure a lot of this is true. What > EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA > bootstrap SPI) contracts changed in 5.0? Minor changes so far: Some org.hibernate.jpa.boot.scan.spi package changes to org.hibernate.boot.archive.scan.spi. Configuration.USE_NEW_ID_GENERATOR_MAPPINGS is now AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS. > > As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, > but we currently do not use it. So that actually should also not cause > any issues in regards to Hibernate 4.x or 5.0 We are not passing the IndexView in currently (we could if that becomes important in the future, as long as we don't keep a reference to the JandexView after the EMF is created). I don't think that would be helpful though as you need changes for XML file handling I think.

> > As far as using the standard JPA bootstrap SPIs, I agree this is up to > Scott. But it simply will not work for the way WildFly does stuff as I > understand it. This is really the first time that I have heard a complaint. I think its a timing issue, that people (like Sanne) have work to do but cannot get to it until WildFly switches to Hibernate 5.0.

> > Second-level cache, yes, is a whole other ball of wax :) Yep, sometimes the second-level cache breaks in ways that we don't detect, when we upgrade WildFly to a newer Infinispan version. > > > On Thu, May 28, 2015 at 9:18 AM, Jason Greene <jason.greene(a)redhat.com > <mailto:jason.greene@redhat.com>> wrote: > > We implement the standard JPA integration SPI, but it is absolutely > awful. > > It forces: > > - The construction of duplicate class loaders with duplicate class > definitions of every class in the deployment > - Repeated runs of the deployment process > - Double loading of any class related to JPA (and its dependencies) > - The JPA provider to use reflection for all annotation discovery > - Double use of reflection in the deployment process > - Bugs from chicken and egg problems > - Increased memory usage > > So for this reason WildFly and Hibernate have their own integration > SPIs, and those SPIs are changing in hibernate 5. So WildFly (well > currently JIPPAJAPPA) needs an update to be compatible with them. > Additionally we have the Jandex 2 change which is pending that both > projects are attempting to align on. > > Now what I am not sure about, Scott will have to answer this. Is if > you can use the standard JPA integration SPI with newer versions of > Hibernate and just live with the nastiness it brings. > > However, there is still a secondary issue, which I am sure you > already know about is that the second level cache and hibernate > search have integrations that need to be compatible and in sync and > tested. > > > On May 28, 2015, at 5:30 AM, Sanne Grinovero <sanne(a)hibernate.org > <mailto:sanne@hibernate.org>> wrote: > > > > Could someone explain please, why it's hard to have a deployer just > > use a different JPA implementor which the user might want to provide? > > > > I'm pretty sure I know how to start a JPA context in plain > JavaSE, and > > don't need to know which implementor version I'm going to use, other > > than for sake of configuration. > > > > The WildFly documentation mentions this property > > "jboss.as.jpa.providerModule", which sounds great on paper and it > > would be a nice usability improvement if it would also actually work > > as it suggests. > > > > There's plenty of evidence on StackOverflow that the current > > limitations are unexpected. For example, Spring moved to Hibernate 5 > > and people won't be able to use your stable line of the application > > server with Spring; I'd hope we could implement a plan to prevent > this > > from happening at the next upgrade cycles. > > > > Thanks, > > Sanne > > > > On 21 May 2015 at 20:10, Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@redhat.com>> wrote: > >> > >> > >> On 05/21/2015 03:05 PM, Tomaž Cerar wrote: > >>> Scott, > >>> > >>> if you do one last jipijapa release that adds "support" for > hibernate5 > >>> hibernate guys could take that version and override it in > wildfly 9 same > >>> way as they add new h5 modules. > >> > >> I assume this will be an iterative process but sure, we could > also push > >> a release of the JIPI-31 branch. Lets keep talking about what > is needed... > >> > >>> > >>> -- > >>> tomaz > >>> > >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow > <smarlow(a)redhat.com <mailto:smarlow@redhat.com> > >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: > >>> > >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: > >>>> Scott, No way to make ORM 5 work in 9 at all? With the user > setting the additional slotted modules of course. > >>> > >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the > >>> integration code that we will look at merging into WildFly > 10. Are you > >>> looking for a custom WildFly 9.x branch or actual changes in > WildFly 9 > >>> (doesn't seem as likely to me but I don't control the schedule)? > >>> > >>>> > >>>> It would help speed up the Hibernate 5 stream adoption and avoid > >>> a lot of duplicated work for 6+ months. > >>>> > >>>>> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@redhat.com> > >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: > >>>>> > >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on > >>> this soon > >>>>> for WildFly 10. > >>>>> > >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > >>>>>> Hi all, > >>>>>> I'm attempting to deploy some integration tests on WildFly > >>> 9.0.0.CR1 > >>>>>> to use a preview of Hibernate ORM version 5. > >>>>>> > >>>>>> It seems the JPA deployer isn't allowing me to run such > >>> experiments: > >>>>>> > >>>>>> # First experiment - providerModule set to custom module > >>>>>> > >>>>>> In my first attempt, I create a custom set of jboss modules > which > >>>>>> include the snapshot builds of ORM 5, add them to my > standalone WF9 > >>>>>> instance and set the persistence.xml property: > >>>>>> jboss.as.jpa.providerModule = my-custom-module-name > >>>>>> > >>>>>> and then get: > >>>>>> > >>>>>> Caused by: java.util.ServiceConfigurationError: > >>>>>> org.hibernate.integrator.spi.Integrator: Provider > >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a > subtype > >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) > >>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> > java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) > >>>>>> [rt.jar:1.7.0_51] > >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) > >>> [rt.jar:1.7.0_51] > >>>>>> at > >>> > org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) > >>>>>> at > >>> > org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) > >>>>>> at > >>> > org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) > >>>>>> at > >>> > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) > >>>>>> at > >>> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) > >>>>>> at > >>> > org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) > >>>>>> at > >>> > org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) > >>>>>> at > >>> > org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) > >>>>>> at > >>> > org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) > >>>>>> ... 7 more > >>>>>> > >>>>>> Clearly it looks like I'm being served classes from the bundled > >>>>>> Hibernate 4.x implementation - on top of those from the > module I'm > >>>>>> requesting. This isn't what the deployer should be doing, right? > >>>>>> > >>>>>> # Second experiment - use the "application provided" > >>>>>> > >>>>>> In this case I hope to hint the JPA deployer to not add the > >>> default > >>>>>> implementor but look for a JPA implementation within my > deployment, > >>>>>> but still package my custom Hibernate build as a module. > >>>>>> > >>>>>> - use the same custom module containing Hibernate ORM 5 (a > >>> preview snapshot) > >>>>>> - Add a "Dependency:" section to the manifest to import (and > >>> export) > >>>>>> my custom module > >>>>>> - set the "jboss.as.jpa.providerModule" property to value > >>> "application" > >>>>>> > >>>>>> This gets me: > >>>>>> > >>>>>> Caused by: > >>> > org.jboss.as.server.deployment.DeploymentUnitProcessingException: > >>>>>> WFLYJPA0027: Persistence provider module load error application > >>> (class > >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > >>>>>> at > >>> > org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > >>>>>> ... 5 more > >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: > >>> application:main > >>>>>> at > org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > >>>>>> [jboss-modules.jar:1.4.3.Final] > >>>>>> at > >>> > org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > >>>>>> at > >>> > org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > >>>>>> ... 10 more > >>>>>> > >>>>>> Remarks: > >>>>>> - it's attempting to load the "application:main" module?! > >>> that's not > >>>>>> what I'd expect from reading [1] > >>>>> > >>>>> This seems to be a bug. I hit it a few days ago when I packaged > >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and > >>> forgot to > >>>>> set the persistence provider in persistence.xml. > >>>>> > >>>>>> - the provider should be available to the deployment > >>> classpath, so > >>>>>> I'm not sure why it's not finding the Provider? (I'm even > exporting > >>>>>> it, although I'm not sure if that was required). > >>>>> > >>>>> Providers are always found through the > >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly > >>> from the > >>>>> deployment classpath. > >>>>> > >>>>>> > >>>>>> Any suggestions to get this running please? > >>>>>> > >>>>>> Also I wonder if some of these should warrant opening a JIRA, > >>> but I'm > >>>>>> not sure how far I misunderstood the intentions of these JPA > >>> deployer > >>>>>> properties. > >>>>> > >>>>> Lets talk in a few days again on IRC. > >>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Sanne > >>>>>> > >>>>>> [1] - > >>> > https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... > >>>>> _______________________________________________ > >>>>> wildfly-dev mailing list > >>>>> wildfly-dev(a)lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org>> > >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev(a)lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org>> > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >>> > >>> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

I discussed this last point with Scott. I'd prefer to drop support for 4.x in WildFly 10. Ideally if that could mean "archiving" that support so users could easily drop it in *if they chose*, great.

On Thu, May 28, 2015 at 10:56 AM, Jason Greene <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: > On May 28, 2015, at 10:42 AM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: > > > > On 05/28/2015 10:29 AM, Steve Ebersole wrote: >> I am just not sure a lot of this is true. What >> EntityManagerFactoryBuilder (the proprietary Hibernate 2-Phase JPA >> bootstrap SPI) contracts changed in 5.0? > > Minor changes so far: > > Some org.hibernate.jpa.boot.scan.spi package changes to org.hibernate.boot.archive.scan.spi. > > Configuration.USE_NEW_ID_GENERATOR_MAPPINGS is now AvailableSettings.USE_NEW_ID_GENERATOR_MAPPINGS. > >> >> As for Jandex version, 5.0 is not using Jandex. We accept a IndexView, >> but we currently do not use it. So that actually should also not cause >> any issues in regards to Hibernate 4.x or 5.0 > > We are not passing the IndexView in currently (we could if that becomes important in the future, as long as we don't keep a reference to the JandexView after the EMF is created). I don't think that would be helpful though as you need changes for XML file handling I think. That should be the eventual goal. We don’t want to process all classes for annotations N times for every framework that wants to read them, as it hurts deployment time. We had this before, we really need to bring it back. > >> >> As far as using the standard JPA bootstrap SPIs, I agree this is up to >> Scott. But it simply will not work for the way WildFly does stuff as I >> understand it. > > This is really the first time that I have heard a complaint. I think its a timing issue, that people (like Sanne) have work to do but cannot get to it until WildFly switches to Hibernate 5.0. We tend to update to the latest hibernate revs very quickly, so I haven’t seen much either, and so it might not be worth “supporting". It’s usually supporting old versions of hibernate that comes up, but I think thats largely been addressed (we have integrations for 3 etc). > >> >> Second-level cache, yes, is a whole other ball of wax :) > > Yep, sometimes the second-level cache breaks in ways that we don't detect, when we upgrade WildFly to a newer Infinispan version. > >> >> >> On Thu, May 28, 2015 at 9:18 AM, Jason Greene <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com> >> <mailto:jason.greene@redhat.com <mailto:jason.greene@redhat.com>>> wrote: >> >> We implement the standard JPA integration SPI, but it is absolutely >> awful. >> >> It forces: >> >> - The construction of duplicate class loaders with duplicate class >> definitions of every class in the deployment >> - Repeated runs of the deployment process >> - Double loading of any class related to JPA (and its dependencies) >> - The JPA provider to use reflection for all annotation discovery >> - Double use of reflection in the deployment process >> - Bugs from chicken and egg problems >> - Increased memory usage >> >> So for this reason WildFly and Hibernate have their own integration >> SPIs, and those SPIs are changing in hibernate 5. So WildFly (well >> currently JIPPAJAPPA) needs an update to be compatible with them. >> Additionally we have the Jandex 2 change which is pending that both >> projects are attempting to align on. >> >> Now what I am not sure about, Scott will have to answer this. Is if >> you can use the standard JPA integration SPI with newer versions of >> Hibernate and just live with the nastiness it brings. >> >> However, there is still a secondary issue, which I am sure you >> already know about is that the second level cache and hibernate >> search have integrations that need to be compatible and in sync and >> tested. >> >> > On May 28, 2015, at 5:30 AM, Sanne Grinovero <sanne(a)hibernate.org <mailto:sanne@hibernate.org> >> <mailto:sanne@hibernate.org <mailto:sanne@hibernate.org>>> wrote: >> > >> > Could someone explain please, why it's hard to have a deployer just >> > use a different JPA implementor which the user might want to provide? >> > >> > I'm pretty sure I know how to start a JPA context in plain >> JavaSE, and >> > don't need to know which implementor version I'm going to use, other >> > than for sake of configuration. >> > >> > The WildFly documentation mentions this property >> > "jboss.as.jpa.providerModule", which sounds great on paper and it >> > would be a nice usability improvement if it would also actually work >> > as it suggests. >> > >> > There's plenty of evidence on StackOverflow that the current >> > limitations are unexpected. For example, Spring moved to Hibernate 5 >> > and people won't be able to use your stable line of the application >> > server with Spring; I'd hope we could implement a plan to prevent >> this >> > from happening at the next upgrade cycles. >> > >> > Thanks, >> > Sanne >> > >> > On 21 May 2015 at 20:10, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: >> >> >> >> >> >> On 05/21/2015 03:05 PM, Tomaž Cerar wrote: >> >>> Scott, >> >>> >> >>> if you do one last jipijapa release that adds "support" for >> hibernate5 >> >>> hibernate guys could take that version and override it in >> wildfly 9 same >> >>> way as they add new h5 modules. >> >> >> >> I assume this will be an iterative process but sure, we could >> also push >> >> a release of the JIPI-31 branch. Lets keep talking about what >> is needed... >> >> >> >>> >> >>> -- >> >>> tomaz >> >>> >> >>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >> <smarlow(a)redhat.com <mailto:smarlow@redhat.com> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>> >> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>>> wrote: >> >>> >> >>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >> >>>> Scott, No way to make ORM 5 work in 9 at all? With the user >> setting the additional slotted modules of course. >> >>> >> >>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >> >>> integration code that we will look at merging into WildFly >> 10. Are you >> >>> looking for a custom WildFly 9.x branch or actual changes in >> WildFly 9 >> >>> (doesn't seem as likely to me but I don't control the schedule)? >> >>> >> >>>> >> >>>> It would help speed up the Hibernate 5 stream adoption and avoid >> >>> a lot of duplicated work for 6+ months. >> >>>> >> >>>>> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>> >> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>>> wrote: >> >>>>> >> >>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >> >>> this soon >> >>>>> for WildFly 10. >> >>>>> >> >>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> >>>>>> Hi all, >> >>>>>> I'm attempting to deploy some integration tests on WildFly >> >>> 9.0.0.CR1 >> >>>>>> to use a preview of Hibernate ORM version 5. >> >>>>>> >> >>>>>> It seems the JPA deployer isn't allowing me to run such >> >>> experiments: >> >>>>>> >> >>>>>> # First experiment - providerModule set to custom module >> >>>>>> >> >>>>>> In my first attempt, I create a custom set of jboss modules >> which >> >>>>>> include the snapshot builds of ORM 5, add them to my >> standalone WF9 >> >>>>>> instance and set the persistence.xml property: >> >>>>>> jboss.as.jpa.providerModule = my-custom-module-name >> >>>>>> >> >>>>>> and then get: >> >>>>>> >> >>>>>> Caused by: java.util.ServiceConfigurationError: >> >>>>>> org.hibernate.integrator.spi.Integrator: Provider >> >>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a >> subtype >> >>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >> >>> [rt.jar:1.7.0_51] >> >>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >> >>> [rt.jar:1.7.0_51] >> >>>>>> at >> >>> >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> >>>>>> [rt.jar:1.7.0_51] >> >>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >> >>> [rt.jar:1.7.0_51] >> >>>>>> at >> >>> >> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> >>>>>> at >> >>> >> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >> >>>>>> at >> >>> >> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> >>>>>> at >> >>> >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> >>>>>> at >> >>> >> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >> >>>>>> at >> >>> >> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> >>>>>> at >> >>> >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> >>>>>> at >> >>> >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> >>>>>> at >> >>> >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> >>>>>> ... 7 more >> >>>>>> >> >>>>>> Clearly it looks like I'm being served classes from the bundled >> >>>>>> Hibernate 4.x implementation - on top of those from the >> module I'm >> >>>>>> requesting. This isn't what the deployer should be doing, right? >> >>>>>> >> >>>>>> # Second experiment - use the "application provided" >> >>>>>> >> >>>>>> In this case I hope to hint the JPA deployer to not add the >> >>> default >> >>>>>> implementor but look for a JPA implementation within my >> deployment, >> >>>>>> but still package my custom Hibernate build as a module. >> >>>>>> >> >>>>>> - use the same custom module containing Hibernate ORM 5 (a >> >>> preview snapshot) >> >>>>>> - Add a "Dependency:" section to the manifest to import (and >> >>> export) >> >>>>>> my custom module >> >>>>>> - set the "jboss.as.jpa.providerModule" property to value >> >>> "application" >> >>>>>> >> >>>>>> This gets me: >> >>>>>> >> >>>>>> Caused by: >> >>> >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> >>>>>> WFLYJPA0027: Persistence provider module load error application >> >>> (class >> >>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> >>>>>> at >> >>> >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> >>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> >>>>>> ... 5 more >> >>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >> >>> application:main >> >>>>>> at >> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> >>>>>> [jboss-modules.jar:1.4.3.Final] >> >>>>>> at >> >>> >> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> >>>>>> at >> >>> >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> >>>>>> ... 10 more >> >>>>>> >> >>>>>> Remarks: >> >>>>>> - it's attempting to load the "application:main" module?! >> >>> that's not >> >>>>>> what I'd expect from reading [1] >> >>>>> >> >>>>> This seems to be a bug. I hit it a few days ago when I packaged >> >>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >> >>> forgot to >> >>>>> set the persistence provider in persistence.xml. >> >>>>> >> >>>>>> - the provider should be available to the deployment >> >>> classpath, so >> >>>>>> I'm not sure why it's not finding the Provider? (I'm even >> exporting >> >>>>>> it, although I'm not sure if that was required). >> >>>>> >> >>>>> Providers are always found through the >> >>>>> javax.persistence.spi.PersistenceProviderResolver, not directly >> >>> from the >> >>>>> deployment classpath. >> >>>>> >> >>>>>> >> >>>>>> Any suggestions to get this running please? >> >>>>>> >> >>>>>> Also I wonder if some of these should warrant opening a JIRA, >> >>> but I'm >> >>>>>> not sure how far I misunderstood the intentions of these JPA >> >>> deployer >> >>>>>> properties. >> >>>>> >> >>>>> Lets talk in a few days again on IRC. >> >>>>> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Sanne >> >>>>>> >> >>>>>> [1] - >> >>> >> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >> >>>>> _______________________________________________ >> >>>>> wildfly-dev mailing list >> >>>>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>> >> >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>> _______________________________________________ >> >>> wildfly-dev mailing list >> >>> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>>> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >>> >> >>> >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

On May 28, 2015, at 10:26 AM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: One issue for the Hibernate projects like Search, is that they need Hibernate 5 to be included in WildFly, so they can start integrating with Hibernate 5 (with the understanding that WildFly 10 will include Hibernate 5). Part of this effort of integrating Hibernate 5, will be passing the various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some TCK runs with Hibernate 5, we will have a better idea of how much work is remaining on the Hibernate ORM 5.x side. From a scheduling point of view, I'm not sure what will be done by August. We can either merge components changes in before they are known to pass all TCK tests or wait until they are ready. Since we are short on time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into WildFly 10) but am flexible on that if the schedule could be flexible also.

On 05/28/2015 11:47 AM, Jason Greene wrote: > >> On May 28, 2015, at 10:26 AM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> >> One issue for the Hibernate projects like Search, is that they need Hibernate 5 to be included in WildFly, so they can start integrating with Hibernate 5 (with the understanding that WildFly 10 will include Hibernate 5). Part of this effort of integrating Hibernate 5, will be passing the various TCKs (from standalone JPA 2.1 TCK to EE TCKs). Once we have some TCK runs with Hibernate 5, we will have a better idea of how much work is remaining on the Hibernate ORM 5.x side. >> >> From a scheduling point of view, I'm not sure what will be done by August. We can either merge components changes in before they are known to pass all TCK tests or wait until they are ready. Since we are short on time, I wanted to pass the TCK tests before (merging Hibernate 5.0 into WildFly 10) but am flexible on that if the schedule could be flexible also. > > I liked your idea on HipChat. You could create a JPA branch and get it far enough along to run the JPA tck tests on it, and in the meantime everyone could fork that branch as needed for their development branches. Once we get promising looking results the branch can be converted into one or more PRs. This works for me, I mostly just wanted to get the Hibernate concerns about the schedule on the table (if there are any concerns). The only one that I know is that they would like Hibernate 5 support now, so Hibernate non-ORM projects can target WildFly now. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

new query engine, but don’t remember if that was for 5 or the future.

Could someone explain please, why it's hard to have a deployer just use a different JPA implementor which the user might want to provide?

I'm pretty sure I know how to start a JPA context in plain JavaSE, and don't need to know which implementor version I'm going to use, other than for sake of configuration. The WildFly documentation mentions this property "jboss.as.jpa.providerModule", which sounds great on paper and it would be a nice usability improvement if it would also actually work as it suggests.

There's plenty of evidence on StackOverflow that the current limitations are unexpected. For example, Spring moved to Hibernate 5 and people won't be able to use your stable line of the application server with Spring; I'd hope we could implement a plan to prevent this from happening at the next upgrade cycles.

Thanks, Sanne On 21 May 2015 at 20:10, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > > On 05/21/2015 03:05 PM, Tomaž Cerar wrote: >> Scott, >> >> if you do one last jipijapa release that adds "support" for hibernate5 >> hibernate guys could take that version and override it in wildfly 9 same >> way as they add new h5 modules. > > I assume this will be an iterative process but sure, we could also push > a release of the JIPI-31 branch. Lets keep talking about what is needed... > >> >> -- >> tomaz >> >> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow <smarlow(a)redhat.com >> <mailto:smarlow@redhat.com>> wrote: >> >> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >> > Scott, No way to make ORM 5 work in 9 at all? With the user setting the additional slotted modules of course. >> >> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 contains the >> integration code that we will look at merging into WildFly 10. Are you >> looking for a custom WildFly 9.x branch or actual changes in WildFly 9 >> (doesn't seem as likely to me but I don't control the schedule)? >> >> > >> > It would help speed up the Hibernate 5 stream adoption and avoid >> a lot of duplicated work for 6+ months. >> > >> >> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com >> <mailto:smarlow@redhat.com>> wrote: >> >> >> >> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >> this soon >> >> for WildFly 10. >> >> >> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> >>> Hi all, >> >>> I'm attempting to deploy some integration tests on WildFly >> 9.0.0.CR1 >> >>> to use a preview of Hibernate ORM version 5. >> >>> >> >>> It seems the JPA deployer isn't allowing me to run such >> experiments: >> >>> >> >>> # First experiment - providerModule set to custom module >> >>> >> >>> In my first attempt, I create a custom set of jboss modules which >> >>> include the snapshot builds of ORM 5, add them to my standalone WF9 >> >>> instance and set the persistence.xml property: >> >>> jboss.as.jpa.providerModule = my-custom-module-name >> >>> >> >>> and then get: >> >>> >> >>> Caused by: java.util.ServiceConfigurationError: >> >>> org.hibernate.integrator.spi.Integrator: Provider >> >>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >> >>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >> [rt.jar:1.7.0_51] >> >>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >> [rt.jar:1.7.0_51] >> >>> at >> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> >>> [rt.jar:1.7.0_51] >> >>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >> [rt.jar:1.7.0_51] >> >>> at >> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> >>> at >> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >> >>> at >> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> >>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> >>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >> >>> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >> >>> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> >>> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> >>> at >> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >> >>> at >> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> >>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> >>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> >>> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> >>> ... 7 more >> >>> >> >>> Clearly it looks like I'm being served classes from the bundled >> >>> Hibernate 4.x implementation - on top of those from the module I'm >> >>> requesting. This isn't what the deployer should be doing, right? >> >>> >> >>> # Second experiment - use the "application provided" >> >>> >> >>> In this case I hope to hint the JPA deployer to not add the >> default >> >>> implementor but look for a JPA implementation within my deployment, >> >>> but still package my custom Hibernate build as a module. >> >>> >> >>> - use the same custom module containing Hibernate ORM 5 (a >> preview snapshot) >> >>> - Add a "Dependency:" section to the manifest to import (and >> export) >> >>> my custom module >> >>> - set the "jboss.as.jpa.providerModule" property to value >> "application" >> >>> >> >>> This gets me: >> >>> >> >>> Caused by: >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> >>> WFLYJPA0027: Persistence provider module load error application >> (class >> >>> org.hibernate.jpa.HibernatePersistenceProvider) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> >>> at >> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> >>> at >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> >>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> >>> ... 5 more >> >>> Caused by: org.jboss.modules.ModuleNotFoundException: >> application:main >> >>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> >>> [jboss-modules.jar:1.4.3.Final] >> >>> at >> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> >>> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> >>> ... 10 more >> >>> >> >>> Remarks: >> >>> - it's attempting to load the "application:main" module?! >> that's not >> >>> what I'd expect from reading [1] >> >> >> >> This seems to be a bug. I hit it a few days ago when I packaged >> >> Hibernate ORM 4.1.x with an application (in a unit test) and >> forgot to >> >> set the persistence provider in persistence.xml. >> >> >> >>> - the provider should be available to the deployment >> classpath, so >> >>> I'm not sure why it's not finding the Provider? (I'm even exporting >> >>> it, although I'm not sure if that was required). >> >> >> >> Providers are always found through the >> >> javax.persistence.spi.PersistenceProviderResolver, not directly >> from the >> >> deployment classpath. >> >> >> >>> >> >>> Any suggestions to get this running please? >> >>> >> >>> Also I wonder if some of these should warrant opening a JIRA, >> but I'm >> >>> not sure how far I misunderstood the intentions of these JPA >> deployer >> >>> properties. >> >> >> >> Lets talk in a few days again on IRC. >> >> >> >>> >> >>> Thanks, >> >>> Sanne >> >>> >> >>> [1] - >> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: "Scott Marlow" <smarlow(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Thursday, May 28, 2015 9:38:08 AM Subject: Re: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 > On May 28, 2015, at 9:56 AM, Scott Marlow <smarlow(a)redhat.com&gt; > wrote: > > > On 05/28/2015 06:30 AM, Sanne Grinovero wrote: >> Could someone explain please, why it's hard to have a deployer >> just >> use a different JPA implementor which the user might want to >> provide? > > If you mean Hibernate 5.x specifically, we started the integration > on > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 > >> >> I'm pretty sure I know how to start a JPA context in plain JavaSE, >> and >> don't need to know which implementor version I'm going to use, >> other >> than for sake of configuration. >> >> The WildFly documentation mentions this property >> "jboss.as.jpa.providerModule", which sounds great on paper and it >> would be a nice usability improvement if it would also actually >> work >> as it suggests. > > You are complaining a lot lately. We purposely designed for known > use > cases. There are other ways to get the dynamic environment that > you are > looking for then complaining that the WildFly JPA subsystem > "jboss.as.jpa.providerModule" option doesn't work. I have probably missed other threads, but I didn’t take it as a complaint, just more surprise and questioning if the behavior made sense. Although, I shouldn’t speak for Sanne. I think its a sign that we may need to improve our docs in this area, so that the limitations are a bit more clear. As always I think its great for us to discuss if and how our integrations could be better. > >> >> There's plenty of evidence on StackOverflow that the current >> limitations are unexpected. For example, Spring moved to Hibernate >> 5 >> and people won't be able to use your stable line of the >> application >> server with Spring; I'd hope we could implement a plan to prevent >> this >> from happening at the next upgrade cycles. > > The question is whether the Hibernate 5.0 release schedule can > align > with the WildFly 10 schedule, so that we can do the work. Getting 5 into 10 as early as possible would be great. We are aiming for a final release in Oct, which isn’t that far away.

> >> >> Thanks, >> Sanne >> >> On 21 May 2015 at 20:10, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >>> >>> >>> On 05/21/2015 03:05 PM, Tomaž Cerar wrote: >>>> Scott, >>>> >>>> if you do one last jipijapa release that adds "support" for >>>> hibernate5 >>>> hibernate guys could take that version and override it in >>>> wildfly 9 same >>>> way as they add new h5 modules. >>> >>> I assume this will be an iterative process but sure, we could >>> also push >>> a release of the JIPI-31 branch. Lets keep talking about what is >>> needed... >>> >>>> >>>> -- >>>> tomaz >>>> >>>> On Thu, May 21, 2015 at 9:01 PM, Scott Marlow >>>> <smarlow(a)redhat.com >>>> <mailto:smarlow@redhat.com>> wrote: >>>> >>>> On 05/21/2015 02:11 PM, Emmanuel Bernard wrote: >>>>> Scott, No way to make ORM 5 work in 9 at all? With the user >>>>> setting the additional slotted modules of course. >>>> >>>> https://github.com/scottmarlow/jipijapa/tree/JIPI-31 >>>> contains the >>>> integration code that we will look at merging into WildFly >>>> 10. Are you >>>> looking for a custom WildFly 9.x branch or actual changes in >>>> WildFly 9 >>>> (doesn't seem as likely to me but I don't control the >>>> schedule)? >>>> >>>>> >>>>> It would help speed up the Hibernate 5 stream adoption and >>>>> avoid >>>> a lot of duplicated work for 6+ months. >>>>> >>>>>> On 21 mai 2015, at 16:36, Scott Marlow <smarlow(a)redhat.com >>>> <mailto:smarlow@redhat.com>> wrote: >>>>>> >>>>>> Hibernate ORM 5.0 doesn't work yet on WildFly. Will push on >>>> this soon >>>>>> for WildFly 10. >>>>>> >>>>>>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>>>>> Hi all, >>>>>>> I'm attempting to deploy some integration tests on WildFly >>>> 9.0.0.CR1 >>>>>>> to use a preview of Hibernate ORM version 5. >>>>>>> >>>>>>> It seems the JPA deployer isn't allowing me to run such >>>> experiments: >>>>>>> >>>>>>> # First experiment - providerModule set to custom module >>>>>>> >>>>>>> In my first attempt, I create a custom set of jboss modules >>>>>>> which >>>>>>> include the snapshot builds of ORM 5, add them to my >>>>>>> standalone WF9 >>>>>>> instance and set the persistence.xml property: >>>>>>> jboss.as.jpa.providerModule = my-custom-module-name >>>>>>> >>>>>>> and then get: >>>>>>> >>>>>>> Caused by: java.util.ServiceConfigurationError: >>>>>>> org.hibernate.integrator.spi.Integrator: Provider >>>>>>> org.hibernate.envers.boot.internal.EnversIntegrator not a >>>>>>> subtype >>>>>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>>> [rt.jar:1.7.0_51] >>>>>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>>> [rt.jar:1.7.0_51] >>>>>>> at >>>> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>>>>> [rt.jar:1.7.0_51] >>>>>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>>> [rt.jar:1.7.0_51] >>>>>>> at >>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>>>>> at >>>> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >>>>>>> at >>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >>>>>>> at >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >>>>>>> at >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>>>>> at >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>>>>> at >>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >>>>>>> at >>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>>>>> at >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>>>>> ... 7 more >>>>>>> >>>>>>> Clearly it looks like I'm being served classes from the >>>>>>> bundled >>>>>>> Hibernate 4.x implementation - on top of those from the >>>>>>> module I'm >>>>>>> requesting. This isn't what the deployer should be doing, >>>>>>> right? >>>>>>> >>>>>>> # Second experiment - use the "application provided" >>>>>>> >>>>>>> In this case I hope to hint the JPA deployer to not add the >>>> default >>>>>>> implementor but look for a JPA implementation within my >>>>>>> deployment, >>>>>>> but still package my custom Hibernate build as a module. >>>>>>> >>>>>>> - use the same custom module containing Hibernate ORM 5 (a >>>> preview snapshot) >>>>>>> - Add a "Dependency:" section to the manifest to import (and >>>> export) >>>>>>> my custom module >>>>>>> - set the "jboss.as.jpa.providerModule" property to value >>>> "application" >>>>>>> >>>>>>> This gets me: >>>>>>> >>>>>>> Caused by: >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>>>>> WFLYJPA0027: Persistence provider module load error >>>>>>> application >>>> (class >>>>>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>>>>> at >>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>>>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>>>>> ... 5 more >>>>>>> Caused by: org.jboss.modules.ModuleNotFoundException: >>>> application:main >>>>>>> at >>>>>>> org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>>>>> [jboss-modules.jar:1.4.3.Final] >>>>>>> at >>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>>>>> at >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>>>>> ... 10 more >>>>>>> >>>>>>> Remarks: >>>>>>> - it's attempting to load the "application:main" module?! >>>> that's not >>>>>>> what I'd expect from reading [1] >>>>>> >>>>>> This seems to be a bug. I hit it a few days ago when I >>>>>> packaged >>>>>> Hibernate ORM 4.1.x with an application (in a unit test) and >>>> forgot to >>>>>> set the persistence provider in persistence.xml. >>>>>> >>>>>>> - the provider should be available to the deployment >>>> classpath, so >>>>>>> I'm not sure why it's not finding the Provider? (I'm even >>>>>>> exporting >>>>>>> it, although I'm not sure if that was required). >>>>>> >>>>>> Providers are always found through the >>>>>> javax.persistence.spi.PersistenceProviderResolver, not >>>>>> directly >>>> from the >>>>>> deployment classpath. >>>>>> >>>>>>> >>>>>>> Any suggestions to get this running please? >>>>>>> >>>>>>> Also I wonder if some of these should warrant opening a JIRA, >>>> but I'm >>>>>>> not sure how far I misunderstood the intentions of these JPA >>>> deployer >>>>>>> properties. >>>>>> >>>>>> Lets talk in a few days again on IRC. >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Sanne >>>>>>> >>>>>>> [1] - >>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >>>>>> _______________________________________________ >>>>>> wildfly-dev mailing list >>>>>> wildfly-dev(a)lists.jboss.org >>>>>> <mailto:wildfly-dev@lists.jboss.org> >>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev(a)lists.jboss.org >>>> <mailto:wildfly-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 28 May 2015 at 16:38, Jason Greene <jason.greene(a)redhat.com&gt; wrote: > >> On May 28, 2015, at 9:56 AM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> >> >> On 05/28/2015 06:30 AM, Sanne Grinovero wrote: >>> Could someone explain please, why it's hard to have a deployer just >>> use a different JPA implementor which the user might want to provide? >> >> If you mean Hibernate 5.x specifically, we started the integration on >> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 Thanks that's very nice, but I'm really just asking why such adapters are needed, and understand their purpose.

For example since I have primarily "preview testing" needs I wonder if we could do something similar within our testing utilities, so to avoid bothering you in future for each and every update we might want to test.

Another example could be to see if it makes sense to include the adapters within the Hibernate feature packs for WildFly - if the integration API is stable enough for the adapter to work with various servers that could lead us to work more together on jipijapa long before it's integrated in WF. For us it's not practical to lock Hibernate testing to WildFly releases, and doesn't help us to test new versions of Hibernate to run fine on versions of the application server which have already sailed.

>> >>> >>> I'm pretty sure I know how to start a JPA context in plain JavaSE, and >>> don't need to know which implementor version I'm going to use, other >>> than for sake of configuration. >>> >>> The WildFly documentation mentions this property >>> "jboss.as.jpa.providerModule", which sounds great on paper and it >>> would be a nice usability improvement if it would also actually work >>> as it suggests. >> >> You are complaining a lot lately. We purposely designed for known use >> cases. There are other ways to get the dynamic environment that you are >> looking for then complaining that the WildFly JPA subsystem >> "jboss.as.jpa.providerModule" option doesn't work. > > I have probably missed other threads, but I didn’t take it as a complaint, just more surprise and questioning if the behavior made sense. Although, I shouldn’t speak for Sanne. I think its a sign that we may need to improve our docs in this area, so that the limitations are a bit more clear. Correct, and apologies for the wording Scott!

I do realise I'm stretching the limits far beyond their intended usage, it's not shocking me to hit some surprises. I'm actually excited about the possibilities and didn't mean to "complain" but to point out an issue in hope to improve as I'd hope to use it.

The documentation seems to claim this is as easy as to point to the module containing the JPA implementation of choice; that would be extremely handy to solve several testing issues we have - not only with Hibernate Search but across the board. Adding a clarification on which modules are accepted would be nice; although maybe then this option should rather be a closed enumeration of short hand names, rather than give the user the option to freely name any module?

But please let's not change the meaning of this property if there is hope we could eventually get it to work with any custom JPA module. Thanks, Sanne > As always I think its great for us to discuss if and how our integrations could be better. > >> >>> >>> There's plenty of evidence on StackOverflow that the current >>> limitations are unexpected. For example, Spring moved to Hibernate 5 >>> and people won't be able to use your stable line of the application >>> server with Spring; I'd hope we could implement a plan to prevent this >>> from happening at the next upgrade cycles. >> >> The question is whether the Hibernate 5.0 release schedule can align >> with the WildFly 10 schedule, so that we can do the work. > > Getting 5 into 10 as early as possible would be great. We are aiming for a final release in Oct, which isn’t that far away. > >> >>> >>> Thanks, >>> Sanne >>>

Hi all, I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 to use a preview of Hibernate ORM version 5. It seems the JPA deployer isn't allowing me to run such experiments: # First experiment - providerModule set to custom module In my first attempt, I create a custom set of jboss modules which include the snapshot builds of ORM 5, add them to my standalone WF9 instance and set the persistence.xml property: jboss.as.jpa.providerModule = my-custom-module-name and then get: Caused by: java.util.ServiceConfigurationError: org.hibernate.integrator.spi.Integrator: Provider org.hibernate.envers.boot.internal.EnversIntegrator not a subtype at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] at java.util.ServiceLoader.access$300(ServiceLoader.java:181) [rt.jar:1.7.0_51] at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) [rt.jar:1.7.0_51] at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51] at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) at org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) at org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) at org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) at org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) at org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) ... 7 more Clearly it looks like I'm being served classes from the bundled Hibernate 4.x implementation - on top of those from the module I'm requesting. This isn't what the deployer should be doing, right? # Second experiment - use the "application provided" In this case I hope to hint the JPA deployer to not add the default implementor but look for a JPA implementation within my deployment, but still package my custom Hibernate build as a module. - use the same custom module containing Hibernate ORM 5 (a preview snapshot) - Add a "Dependency:" section to the manifest to import (and export) my custom module - set the "jboss.as.jpa.providerModule" property to value "application" This gets me: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYJPA0027: Persistence provider module load error application (class org.hibernate.jpa.HibernatePersistenceProvider) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] ... 5 more Caused by: org.jboss.modules.ModuleNotFoundException: application:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) [jboss-modules.jar:1.4.3.Final] at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) ... 10 more Remarks: - it's attempting to load the "application:main" module?! that's not what I'd expect from reading [1] - the provider should be available to the deployment classpath, so I'm not sure why it's not finding the Provider? (I'm even exporting it, although I'm not sure if that was required). Any suggestions to get this running please? Also I wonder if some of these should warrant opening a JIRA, but I'm not sure how far I misunderstood the intentions of these JPA deployer properties. Thanks, Sanne [1] - https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere...

Hi Scott, finally got back on this upgrade. You were right, the problem is that JipiJapa figures out that I'm using Hibernate - even though I'm not hard coding the provider name, as in that case it will just default to Hibernate anyway - and because of that it's adding both the JPA adaptors for Hibernate 4 and the wrong version of the Hibernate dependencies as well. This is the temporary solution I'm going to use: https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0... Thanks for all pointers! Sanne On 1 June 2015 at 16:08, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > I suspect that this is a bug in WildFly that we need to track down. I'm > guessing that the condition is that we are trying to use a custom Hibernate > module when there is an existing Hibernate module that matches the > Persistence provider name. Or something like that. > > > On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >> >> Hi all, >> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >> to use a preview of Hibernate ORM version 5. >> >> It seems the JPA deployer isn't allowing me to run such experiments: >> >> # First experiment - providerModule set to custom module >> >> In my first attempt, I create a custom set of jboss modules which >> include the snapshot builds of ORM 5, add them to my standalone WF9 >> instance and set the persistence.xml property: >> jboss.as.jpa.providerModule = my-custom-module-name >> >> and then get: >> >> Caused by: java.util.ServiceConfigurationError: >> org.hibernate.integrator.spi.Integrator: Provider >> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >> at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51] >> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >> [rt.jar:1.7.0_51] >> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >> [rt.jar:1.7.0_51] >> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >> [rt.jar:1.7.0_51] >> at >> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >> at >> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >> at >> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >> at >> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >> at >> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >> at >> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >> at >> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >> ... 7 more >> >> Clearly it looks like I'm being served classes from the bundled >> Hibernate 4.x implementation - on top of those from the module I'm >> requesting. This isn't what the deployer should be doing, right? >> >> # Second experiment - use the "application provided" >> >> In this case I hope to hint the JPA deployer to not add the default >> implementor but look for a JPA implementation within my deployment, >> but still package my custom Hibernate build as a module. >> >> - use the same custom module containing Hibernate ORM 5 (a preview >> snapshot) >> - Add a "Dependency:" section to the manifest to import (and export) >> my custom module >> - set the "jboss.as.jpa.providerModule" property to value "application" >> >> This gets me: >> >> Caused by: >> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >> WFLYJPA0027: Persistence provider module load error application (class >> org.hibernate.jpa.HibernatePersistenceProvider) >> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >> at >> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >> at >> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >> ... 5 more >> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >> [jboss-modules.jar:1.4.3.Final] >> at >> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >> at >> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >> ... 10 more >> >> Remarks: >> - it's attempting to load the "application:main" module?! that's not >> what I'd expect from reading [1] >> - the provider should be available to the deployment classpath, so >> I'm not sure why it's not finding the Provider? (I'm even exporting >> it, although I'm not sure if that was required). >> >> Any suggestions to get this running please? >> >> Also I wonder if some of these should warrant opening a JIRA, but I'm >> not sure how far I misunderstood the intentions of these JPA deployer >> properties. >> >> Thanks, >> Sanne >> >> [1] - >> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >> >

On 3 June 2015 at 16:55, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > Hi Sanne, > > I was able to reproduce one of the below errors that occur when packaging > Hibernate ORM jars with the application http://pastie.org/10221793. This is > with the "jboss.as.jpa.providerModule" property set to value "application". > > Test is pushed to [1] and is based on a test that I added for the [2] pull > request. Once [2] is merged to WildFly master, it should be easy to fix the > bug. The only change that I needed to [2], was to remove the provider from > the persistence.xml. > > For the first approach below, we should probably allow the > "jboss.as.jpa.adapterClass" to specify the > "org.jboss.as.jpa.processor.PersistenceProviderAdaptorLoader.noopAdaptor" > (by name or via a special value). Right, being able to "force" usage of the no-op Adaptor like I did with my Byteman rule would give us a lot of nice flexibility. BTW once I did that, I noticed that the scanning of entities broke. Apparently entity scanning for Hibernate requires the Scanner which you would provide with the adaptor; would you know why? I'm wondering because it seems related to an Hibernate OGM issue: in that case we don't disable the adapter but still auto-detection of entities doesn't work. Thanks! Sanne > > Scott > > [1] https://github.com/scottmarlow/wildfly/tree/test_orm41_bundled > > [2] https://github.com/wildfly/wildfly/pull/7509 > > > On 06/02/2015 08:15 PM, Sanne Grinovero wrote: >> >> Hi Scott, >> finally got back on this upgrade. You were right, the problem is that >> JipiJapa figures out that I'm using Hibernate - even though I'm not >> hard coding the provider name, as in that case it will just default to >> Hibernate anyway - and because of that it's adding both the JPA >> adaptors for Hibernate 4 and the wrong version of the Hibernate >> dependencies as well. >> >> This is the temporary solution I'm going to use: >> >> https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0... >> >> Thanks for all pointers! >> Sanne >> >> >> On 1 June 2015 at 16:08, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >>> >>> I suspect that this is a bug in WildFly that we need to track down. I'm >>> guessing that the condition is that we are trying to use a custom >>> Hibernate >>> module when there is an existing Hibernate module that matches the >>> Persistence provider name. Or something like that. >>> >>> >>> On 05/21/2015 07:30 AM, Sanne Grinovero wrote: >>>> >>>> >>>> Hi all, >>>> I'm attempting to deploy some integration tests on WildFly 9.0.0.CR1 >>>> to use a preview of Hibernate ORM version 5. >>>> >>>> It seems the JPA deployer isn't allowing me to run such experiments: >>>> >>>> # First experiment - providerModule set to custom module >>>> >>>> In my first attempt, I create a custom set of jboss modules which >>>> include the snapshot builds of ORM 5, add them to my standalone WF9 >>>> instance and set the persistence.xml property: >>>> jboss.as.jpa.providerModule = my-custom-module-name >>>> >>>> and then get: >>>> >>>> Caused by: java.util.ServiceConfigurationError: >>>> org.hibernate.integrator.spi.Integrator: Provider >>>> org.hibernate.envers.boot.internal.EnversIntegrator not a subtype >>>> at java.util.ServiceLoader.fail(ServiceLoader.java:231) >>>> [rt.jar:1.7.0_51] >>>> at java.util.ServiceLoader.access$300(ServiceLoader.java:181) >>>> [rt.jar:1.7.0_51] >>>> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369) >>>> [rt.jar:1.7.0_51] >>>> at java.util.ServiceLoader$1.next(ServiceLoader.java:445) >>>> [rt.jar:1.7.0_51] >>>> at >>>> >>>> org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.loadJavaServices(ClassLoaderServiceImpl.java:341) >>>> at >>>> >>>> org.hibernate.integrator.internal.IntegratorServiceImpl.<init>(IntegratorServiceImpl.java:57) >>>> at >>>> >>>> org.hibernate.boot.registry.BootstrapServiceRegistryBuilder.build(BootstrapServiceRegistryBuilder.java:247) >>>> at >>>> >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.buildBootstrapServiceRegistry(EntityManagerFactoryBuilderImpl.java:520) >>>> at >>>> >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:208) >>>> at >>>> >>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.<init>(EntityManagerFactoryBuilderImpl.java:188) >>>> at >>>> >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:45) >>>> at >>>> >>>> org.hibernate.jpa.boot.spi.Bootstrap.getEntityManagerFactoryBuilder(Bootstrap.java:57) >>>> at >>>> >>>> org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.<init>(TwoPhaseBootstrapImpl.java:38) >>>> at >>>> >>>> org.jboss.as.jpa.hibernate4.HibernatePersistenceProviderAdaptor.getBootstrap(HibernatePersistenceProviderAdaptor.java:173) >>>> at >>>> >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.createContainerEntityManagerFactoryBuilder(PhaseOnePersistenceUnitServiceImpl.java:243) >>>> at >>>> >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl.access$800(PhaseOnePersistenceUnitServiceImpl.java:60) >>>> at >>>> >>>> org.jboss.as.jpa.service.PhaseOnePersistenceUnitServiceImpl$1$1.run(PhaseOnePersistenceUnitServiceImpl.java:118) >>>> ... 7 more >>>> >>>> Clearly it looks like I'm being served classes from the bundled >>>> Hibernate 4.x implementation - on top of those from the module I'm >>>> requesting. This isn't what the deployer should be doing, right? >>>> >>>> # Second experiment - use the "application provided" >>>> >>>> In this case I hope to hint the JPA deployer to not add the default >>>> implementor but look for a JPA implementation within my deployment, >>>> but still package my custom Hibernate build as a module. >>>> >>>> - use the same custom module containing Hibernate ORM 5 (a preview >>>> snapshot) >>>> - Add a "Dependency:" section to the manifest to import (and export) >>>> my custom module >>>> - set the "jboss.as.jpa.providerModule" property to value >>>> "application" >>>> >>>> This gets me: >>>> >>>> Caused by: >>>> org.jboss.as.server.deployment.DeploymentUnitProcessingException: >>>> WFLYJPA0027: Persistence provider module load error application (class >>>> org.hibernate.jpa.HibernatePersistenceProvider) >>>> at >>>> >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) >>>> at >>>> >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) >>>> at >>>> >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) >>>> at >>>> >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) >>>> at >>>> >>>> org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) >>>> at >>>> >>>> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) >>>> [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] >>>> ... 5 more >>>> Caused by: org.jboss.modules.ModuleNotFoundException: application:main >>>> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) >>>> [jboss-modules.jar:1.4.3.Final] >>>> at >>>> >>>> org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) >>>> at >>>> >>>> org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) >>>> ... 10 more >>>> >>>> Remarks: >>>> - it's attempting to load the "application:main" module?! that's not >>>> what I'd expect from reading [1] >>>> - the provider should be available to the deployment classpath, so >>>> I'm not sure why it's not finding the Provider? (I'm even exporting >>>> it, although I'm not sure if that was required). >>>> >>>> Any suggestions to get this running please? >>>> >>>> Also I wonder if some of these should warrant opening a JIRA, but I'm >>>> not sure how far I misunderstood the intentions of these JPA deployer >>>> properties. >>>> >>>> Thanks, >>>> Sanne >>>> >>>> [1] - >>>> >>>> https://docs.jboss.org/author/display/WFLY9/JPA+Reference+Guide#JPARefere... >>>> >>> > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

# Second experiment - use the "application provided" In this case I hope to hint the JPA deployer to not add the default implementor but look for a JPA implementation within my deployment, but still package my custom Hibernate build as a module. - use the same custom module containing Hibernate ORM 5 (a preview snapshot) - Add a "Dependency:" section to the manifest to import (and export) my custom module - set the "jboss.as.jpa.providerModule" property to value "application" This gets me: Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYJPA0027: Persistence provider module load error application (class org.hibernate.jpa.HibernatePersistenceProvider) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] ... 5 more Caused by: org.jboss.modules.ModuleNotFoundException: application:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) [jboss-modules.jar:1.4.3.Final] at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) ... 10 more Remarks: - it's attempting to load the "application:main" module?!