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

Scott Marlow smarlow at redhat.com
Wed Jun 3 14:20:20 EDT 2015


I'm not really sure why the following doesn't work with EclipseLink + 
Hibernate.  Probably a bad assumption on my part (although it made sense 
when I single stepped through the logic in a debugger and seemed to get 
reasonable results from evaluating the URL).  Our OpenJPA unit test 
seems to work, so maybe someone needs to contribute a Hibernate ORM 
patch (I'm not sure myself why it doesn't just work).   :-)

WildFly (JPA deployer) implementation of 
javax.persistence.spi.PersistenceUnitInfo.getPersistenceUnitRootUrl() 
looks like:

java.net.URL getPersistenceUnitRootUrl() {
   VirtualFile persistence_xml = ... ;
   // persistence.xml parent == META-INF
   // META-INF parent is returned in URL form, which represents PU root
   return persistence_xml.getParent().getParent().toURL();
}

Scott

On 06/03/2015 12:15 PM, Steve Ebersole wrote:
> 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
> <mailto:sanne at hibernate.org>> wrote:
>
>     On 3 June 2015 at 16:55, Scott Marlow <smarlow at redhat.com
>     <mailto: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
>     <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


More information about the wildfly-dev mailing list