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

Wed Jun 3 12:15:23 EDT 2015

Because scanning in WildFly requires VFS hooks that Jipijapa provided in
its scanner specializations.

On Wed, Jun 3, 2015 at 11:10 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> On 3 June 2015 at 16:55, Scott Marlow <smarlow at redhat.com> wrote:
> > Hi Sanne,
> >
> > I was able to reproduce one of the below errors that occur when packaging
> > Hibernate ORM jars with the application http://pastie.org/10221793.
> This is
> > with the "jboss.as.jpa.providerModule" property set to value
> "application".
> >
> > Test is pushed to [1] and is based on a test that I added for the [2]
> pull
> > request.  Once [2] is merged to WildFly master, it should be easy to fix
> the
> > bug.  The only change that I needed to [2], was to remove the provider
> from
> > the persistence.xml.
> >
> > For the first approach below, we should probably allow the
> > "jboss.as.jpa.adapterClass" to specify the
> > "org.jboss.as.jpa.processor.PersistenceProviderAdaptorLoader.noopAdaptor"
> > (by name or via a special value).
>
> Right, being able to "force" usage of the no-op Adaptor like I did
> with my Byteman rule would give us a lot of nice flexibility.
>
> BTW once I did that, I noticed that the scanning of entities broke.
> Apparently entity scanning for Hibernate requires the Scanner which
> you would provide with the adaptor; would you know why?
> I'm wondering because it seems related to an Hibernate OGM issue: in
> that case we don't disable the adapter but still auto-detection of
> entities doesn't work.
>
> Thanks!
> Sanne
>
> >
> > Scott
> >
> > [1] https://github.com/scottmarlow/wildfly/tree/test_orm41_bundled
> >
> > [2] https://github.com/wildfly/wildfly/pull/7509
> >
> >
> > On 06/02/2015 08:15 PM, Sanne Grinovero wrote:
> >>
> >> Hi Scott,
> >> finally got back on this upgrade. You were right, the problem is that
> >> JipiJapa figures out that I'm using Hibernate - even though I'm not
> >> hard coding the provider name, as in that case it will just default to
> >> Hibernate anyway - and because of that it's adding both the JPA
> >> adaptors for Hibernate 4 and the wrong version of the Hibernate
> >> dependencies as well.
> >>
> >> This is the temporary solution I'm going to use:
> >>
> >>
> https://github.com/hibernate/hibernate-search/commit/d2b05ef7511815d6c0a0779734b95a69cdcbf56d
> >>
> >> Thanks for all pointers!
> >> Sanne
> >>
> >>
> >> On 1 June 2015 at 16:08, Scott Marlow <smarlow at redhat.com> wrote:
> >>>
> >>> I suspect that this is a bug in WildFly that we need to track down.
> I'm
> >>> guessing that the condition is that we are trying to use a custom
> >>> Hibernate
> >>> module when there is an existing Hibernate module that matches the
> >>> Persistence provider name.  Or something like that.
> >>>
> >>>
> >>> 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]
> >>>>    - 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).
> >>>>
> >>>> 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.
> >>>>
> >>>> 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
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150603/2bef01eb/attachment.html 