[wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9

Thu May 21 15:05:51 EDT 2015

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 at 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 at 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#JPAReferenceGuide-Persistenceunitproperties
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150521/1681190b/attachment-0001.html 