[wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9
Scott Marlow
smarlow at redhat.com
Thu May 28 12:10:38 EDT 2015
On 05/28/2015 12:00 PM, Steve Ebersole wrote:
> 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.
By drop 4.x into WildFly, I think that we can allow users to copy jars
into a 4.x static module and they can then use the
"jboss.as.jpa.providerModule" hint in their persistence.xml.
>
> On Thu, May 28, 2015 at 10:56 AM, Jason Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>
> > On May 28, 2015, at 10:42 AM, Scott Marlow <smarlow at redhat.com <mailto: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>
> >> <mailto: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>
> >> <mailto: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>
> >> <mailto: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>>
> >> >>> <mailto: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>>
> >> >>> <mailto: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>>
> >> <mailto: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>>
> >> <mailto: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>
> <mailto: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>
> <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
> >>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
More information about the wildfly-dev
mailing list