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

Jason Greene jason.greene at redhat.com
Thu May 28 11:38:08 EDT 2015


> On May 28, 2015, at 9:56 AM, Scott Marlow <smarlow at redhat.com> 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 at 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 at redhat.com
>>>> <mailto: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
>>>>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>     _______________________________________________
>>>>     wildfly-dev mailing list
>>>>     wildfly-dev at lists.jboss.org <mailto: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
>> 
>> _______________________________________________
>> 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

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat




More information about the wildfly-dev mailing list