[wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9
Sanne Grinovero
sanne at hibernate.org
Thu May 28 16:26:12 EDT 2015
On 28 May 2015 at 16:38, Jason Greene <jason.greene at redhat.com> wrote:
>
>> 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
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
>>>
>>> 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