[wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9
Steve Ebersole
steve at hibernate.org
Thu May 28 12:00:40 EDT 2015
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 at redhat.com>
wrote:
>
> > On May 28, 2015, at 10:42 AM, Scott Marlow <smarlow at 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 at redhat.com
> >> <mailto:jason.greene at 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 at hibernate.org
> >> <mailto:sanne at 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 at redhat.com
> >> <mailto: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>
> >> >>> <mailto: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>
> >> >>> <mailto: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>
> >> <mailto: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>
> >> <mailto: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 <mailto: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 <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
> >>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150528/174fd5a7/attachment-0001.html
More information about the wildfly-dev
mailing list