[wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9
Andrig T. Miller
anmiller at redhat.com
Thu May 28 12:07:18 EDT 2015
----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Scott Marlow" <smarlow at redhat.com>
> Cc: wildfly-dev at 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 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.
>
+100. We need 5 in there from the performance teams perspective as early as possible.
Andy
> >
> >>
> >> 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
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
More information about the wildfly-dev
mailing list