[hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status update...

Scott Marlow smarlow at redhat.com
Mon Jun 29 10:49:17 EDT 2015



On 06/29/2015 10:06 AM, Steve Ebersole wrote:
> org.hibernate.property.access.spi.GetterFieldImpl
>
> Its possible something is amiss
> in org.hibernate.property.access.internal.PropertyAccessStrategyFieldImpl,
> but considering GetterFieldImpl is chosen (properly) and that is where
> things break down that is where I would look.

The PropertyAccessFieldImpl ctor is passed with the 'containerJavaType' 
parameter set to class 
org.jboss.as.test.integration.hibernate.search.Book that is defined by 
the javax.persistence.spi.PersistenceUnitInfo.getNewTempClassLoader().

I wonder if 
org.hibernate.boot.internal.ClassLoaderAccessImpl.classForName(String 
name), should use the PersistenceUnitInfo.getClassLoader() instead of 
getNewTempClassLoader(), once we are in the second bootstrap phase 
(which we are when ClassLoaderAccessImpl.classForName(String) is called 
in this particular WildFly test case).

 From a WildFly classloading perspective, once we call 
EntityManagerFactoryBuilderImpl.build(), all application class 
enhancing/rewriting should be complete, so we should prefer the 
PersistenceUnitInfo.getClassLoader() once we reach the second bootstrap 
phase.

>
> I find it strange though that this works in our test suite.  Maybe some
> strange class loader issue?
>
> On Mon, Jun 29, 2015 at 8:18 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     On 06/26/2015 12:12 PM, Sanne Grinovero wrote:
>      > On 26 June 2015 at 15:02, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>> wrote:
>      >> The ISE message is:
>      >> "
>      >> Can not set java.lang.Long field
>      >> org.jboss.as.test.integration.hibernate.search.Book.id
>     <http://org.jboss.as.test.integration.hibernate.search.Book.id> to
>      >> org.jboss.as.test.integration.hibernate.search.Book
>      >> ", which does sound like a bug.
>      >
>      > Hi Scott, could you just make those fields in the test "public",
>     so we
>      > can get an ORM5 version of WildFly to play with? We've lots more work
>      > to do which is blocked by that.
>      >
>      > I've opened HHH-9887 to track this, but I'd treat it as a minor
>      > regression which shouldn't slow us down with integration in WildFly;
>      > not least it would be much more convenient for us to reproduce
>     this if
>      > we upgrade WildFly first.
>
>     Which ORM class should be debugged to find the cause?  The same error
>     occurs whether the 'id' field is public or not (see my comment on
>     HHH-9887).
>
>     The same failure occurs for WildFly tests: HibernateSearchJPATestCase,
>     JPABeanValidationTestCase, DataSourceDefinitionJPATestCase,
>     JPA2LCTestCase, WebJPATestCase.
>
>      >
>      > Thanks,
>      > Sanne
>      >
>      >
>      >>
>      >> On 06/18/2015 01:41 PM, Steve Ebersole wrote:
>      >>>
>      >>> That should still be ok.  If it does not work, that would be a bug.
>      >>>
>      >>> On Thu, Jun 18, 2015 at 11:38 AM Sanne Grinovero
>     <sanne at hibernate.org <mailto:sanne at hibernate.org>
>      >>> <mailto:sanne at hibernate.org <mailto:sanne at hibernate.org>>> wrote:
>      >>>
>      >>>      On 18 June 2015 at 17:17, Scott Marlow <smarlow at redhat.com
>     <mailto:smarlow at redhat.com>
>      >>>      <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>     wrote:
>      >>>       >
>      >>>       >
>      >>>       > On 06/18/2015 11:59 AM, Sanne Grinovero wrote:
>      >>>       >>
>      >>>       >> On 18 June 2015 at 15:55, Scott Marlow
>     <smarlow at redhat.com <mailto:smarlow at redhat.com>
>      >>>      <mailto:smarlow at redhat.com <mailto:smarlow at redhat.com>>>
>     wrote:
>      >>>       >>>
>      >>>       >>> Sanne,
>      >>>       >>>
>      >>>       >>> The [1] pull request to bring Jipijapa source into
>     WildFly
>      >>>      master is
>      >>>       >>> merged.
>      >>>       >>>
>      >>>       >>> I pushed a copy of the (work in progress) ORM 5
>     changes to
>      >>>      github [2].
>      >>>       >>>
>      >>>       >>> Is there a WildFly pull request for the changes to
>     upgrade to
>      >>>      Hibernate
>      >>>       >>> Search 5.4.0.Alpha1?  I didn't see one but I might of
>     missed it.
>      >>>       >>
>      >>>       >>
>      >>>       >> No there isn't, as Hibernate Search 5.4.0.Alpha1
>     *requires*
>      >>>      Hibernate
>      >>>       >> ORM 5.0.0.CR1.
>      >>>       >
>      >>>       >
>      >>>       > What needs to change on WildFly for the Hibernate
>     Search upgrade?
>      >>>
>      >>>
>      >>>      Nothing else changes. Just change the Hibernate Search
>     version when
>      >>>      you change the Hibernate ORM version.
>      >>>
>      >>>       > I started
>      >>>       > with just changing the WildFly (top level) pom.xml to
>     reference HS
>      >>>       > 5.4.0.Alpha1.
>      >>>
>      >>>      +1
>      >>>
>      >>>       >  Do you expect that the latest ORM master branch will work
>      >>>       > with HS 5.4.0.Alpha1 or is ORM 5.0.0.CR1 better?
>      >>>
>      >>>      I didn't test the latest ORM master branch, but it will
>     work with
>      >>>      ORM 5.0.0.CR1.
>      >>>
>      >>>       > Locally, I am building the latest ORM master (built
>     from source)
>      >>>      and using
>      >>>       > Hibernate Search 5.4.0.Alpha1.  When running the WildFly
>      >>>      testsuite, I see a
>      >>>       > few different errors.  One of them is from the
>      >>>       > HibernateSearchJPATestCase.testFullTextQuery test.
>      >>>       > http://pastebin.com/Q5xLrkpT shows the WildFly server.log
>      >>>      contents from the
>      >>>       > Hibernate Search test.
>      >>>
>      >>>      That looks like related to an Hibernate ORM change, not
>     Search.
>      >>>      The entity used for that test doesn't declare the fields
>     as "public";
>      >>>      that used to be ok in previous versions.
>      >>>      You could workaround it by changing the test to use either
>     public
>      >>>      fields or traditional getters/setters?
>      >>>      But we should check with Steve if that change was
>     intentional? For
>      >>>      now, better to workaround it in the test so we don't get
>     stuck.
>      >>>
>      >>>      Thanks!
>      >>>      Sanne
>      >>>
>      >>>       >
>      >>>       >
>      >>>       >>
>      >>>       >> The two should be updated in synch this time, in
>     future there
>      >>>      will be
>      >>>       >> more flexibility.
>      >>>       >>
>      >>>       >>>
>      >>>       >>> Scott
>      >>>       >>>
>      >>>       >>> [1] https://github.com/wildfly/wildfly/pull/7509
>      >>>       >>>
>      >>>       >>> [2]
>     https://github.com/scottmarlow/wildfly/tree/hibernate5_june18
>      >>>      _______________________________________________
>      >>>      hibernate-dev mailing list
>      >>> hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>
>     <mailto:hibernate-dev at lists.jboss.org
>     <mailto:hibernate-dev at lists.jboss.org>>
>      >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>
>      >>
>


More information about the hibernate-dev mailing list