I ran part of the WildFly basic integration tests against the https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch, which includes the following Hibernate versions: ORM 5.0.0.CR1 HCA 4.0.5.Final HS 5.2.0.Final I am seeing the below errors. 1. The Hibernate Search test (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L 2. In the org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache, we are seeing a "java.lang.ClassNotFoundException: org.infinispan.commons.util.CloseableIteratorSet from [Module "org.hibernate.infinispan:main"http://pastie.org/10213943 Scott _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Scott, first please use a SNAPSHOT build as you'll need it for the HCANN fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

As for the ClassNotFoundException, I really do not get this one. So, essentially: 1) hibernate-infinispan is able to access infinispan-core classes 2) hibernate-infinispan makes use of this org/infinispan/commons/util/CloseableIteratorSet class as returned from classes contained in infinispan-core. I am not sure which jar holds org/infinispan/commons/util/CloseableIteratorSet. Anyone?

3) hibernate-infinispan is not able to access org/infinispan/commons/util/CloseableIteratorSet On Fri, May 29, 2015 at 11:57 AM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: Also am using Infinispan 7.2.1.Final but noticed that Infinispan 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master to upgrade Infinispan. On 05/29/2015 12:50 PM, Scott Marlow wrote: > I ran part of the WildFly basic integration tests against the > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch, > which includes the following Hibernate versions: > > ORM 5.0.0.CR1 > HCA 4.0.5.Final > HS 5.2.0.Final > > I am seeing the below errors. > > 1. The Hibernate Search test > (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) > is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L > > 2. In the > org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache, > we are seeing a "java.lang.ClassNotFoundException: > org.infinispan.commons.util.CloseableIteratorSet from [Module > "org.hibernate.infinispan:main"http://pastie.org/10213943 > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

So: 1) hibernate-infinispan seems to be able to see infinispan-core (which is what defines as a dependency) 2) hibernate-infinispan seems to not be able to see infinispan-commons (which I would have to assume infinispan-core defines as a dependency)

This sure seems like a problem in the WF module/classpath set up... On Fri, May 29, 2015 at 1:21 PM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: On 05/29/2015 02:03 PM, Steve Ebersole wrote: > Scott, first please use a SNAPSHOT build as you'll need it for the HCANN > fix I did, or you could just pull in the newest HCANN (5.0.0.Final) Will do. > > As for the ClassNotFoundException, I really do not get this one. So, > essentially: > > 1) hibernate-infinispan is able to access infinispan-core classes > 2) hibernate-infinispan makes use of > this org/infinispan/commons/util/CloseableIteratorSet class as returned > from classes contained in infinispan-core. I am not sure which jar > holds org/infinispan/commons/util/CloseableIteratorSet. Anyone? infinispan-commons-7.2.1.Final.jar contains org.infinispan.commons.util.CloseableIteratorSet > 3) hibernate-infinispan is not able to access > org/infinispan/commons/util/CloseableIteratorSet > > On Fri, May 29, 2015 at 11:57 AM, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> > <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: > > Also am using Infinispan 7.2.1.Final but noticed that Infinispan > 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master > to upgrade Infinispan. > > On 05/29/2015 12:50 PM, Scott Marlow wrote: > > I ran part of the WildFly basic integration tests against the > > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 > branch, > > which includes the following Hibernate versions: > > > > ORM 5.0.0.CR1 > > HCA 4.0.5.Final > > HS 5.2.0.Final > > > > I am seeing the below errors. > > > > 1. The Hibernate Search test > > > (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) > > is failing with an AbstractServiceMethodError > http://pastebin.com/CzEgVp0L > > > > 2. In the > > > org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache, > > we are seeing a "java.lang.ClassNotFoundException: > > org.infinispan.commons.util.CloseableIteratorSet from [Module > > "org.hibernate.infinispan:main"http://pastie.org/10213943 > > > > Scott > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> <mailto:hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> <mailto:hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >

> On 05/29/2015 02:03 PM, Steve Ebersole wrote: >> Scott, first please use a SNAPSHOT build as you'll need it for the HCANN >> fix I did, or you could just pull in the newest HCANN (5.0.0.Final) Should I use a pushed SNAPSHOT? I can build ORM master via "gradlew clean install", however, "gradlew PublishToMavenLocal" fails on "hibernate-osgi:publishMavenJavaPublicationToMavenLocal" with details: " What went wrong: Execution failed for task ':hibernate-osgi:publishMavenJavaPublicationToMavenLocal'. > Failed to publish publication 'mavenJava' to repository 'MavenLocal' > Invalid publication 'mavenJava': artifact file does not exist: '/mnt/ssd/work/hibernate5/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.1-SNAPSHOT-karaf.xml' " _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

I ran part of the WildFly basic integration tests against the https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch, which includes the following Hibernate versions: ORM 5.0.0.CR1 HCA 4.0.5.Final HS 5.2.0.Final I am seeing the below errors. 1. The Hibernate Search test (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L 2. In the org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache, we are seeing a "java.lang.ClassNotFoundException: org.infinispan.commons.util.CloseableIteratorSet from [Module "org.hibernate.infinispan:main"http://pastie.org/10213943 Scott _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 05/29/2015 01:05 PM, Sanne Grinovero wrote: > > Thanks Scott! > > 1. this error is expected: HS 5.2 is not compatible with ORM 5. > We'll need a compatible WildFly version to release a compatible > version, or alternatively know how to get the tests to run w/o the > jipijapa patch as I was trying ;-) In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, we could disable org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase and create a blocking jira for WF10 assigned to you, so you can either enable the HibernateSearchJPATestCase test or remove Search from WildFly 10 as you mention below (as a possible option). Please let me know how you want me to proceed.

Hi Scott, can we expect to see both Hibernate ORM 5 and this latest Hibernate Search version 5.4.0.Alpha1 soon in WildFly 10?

thanks, Sanne On 4 June 2015 at 23:47, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 29 May 2015 at 18:27, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> >> >> On 05/29/2015 01:05 PM, Sanne Grinovero wrote: >>> >>> Thanks Scott! >>> >>> 1. this error is expected: HS 5.2 is not compatible with ORM 5. >>> We'll need a compatible WildFly version to release a compatible >>> version, or alternatively know how to get the tests to run w/o the >>> jipijapa patch as I was trying ;-) >> >> >> In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, we >> could disable >> org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase >> and create a blocking jira for WF10 assigned to you, so you can either >> enable the HibernateSearchJPATestCase test or remove Search from WildFly 10 >> as you mention below (as a possible option). Please let me know how you >> want me to proceed. > > That won't be necessary, as a compatible release is now available: > update Hibernate Search to version 5.4.0.Alpha1 when you upgrade Hibernate ORM. > > (don't upgrade HS w/o ORM to 5: it's required for this version of > Hibernate Search) > > Thanks! > > Sanne

On 17 June 2015 at 13:44, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > > On 06/17/2015 06:44 AM, Sanne Grinovero wrote: >> >> Hi Scott, >> can we expect to see both Hibernate ORM 5 and this latest Hibernate >> Search version 5.4.0.Alpha1 soon in WildFly 10? > > > I hope so. https://github.com/wildfly/wildfly/pull/7509 is passing the > testsuite and I made the suggested code changes. I asked for an ETA on the > PR. The actual update will be done in another PR after that is merged right? I didn't see the update in that one.

Maybe it's worth to include both changes in one pull request?

> > >> >> thanks, >> Sanne >> >> On 4 June 2015 at 23:47, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: >>> >>> On 29 May 2015 at 18:27, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >>>> >>>> >>>> >>>> On 05/29/2015 01:05 PM, Sanne Grinovero wrote: >>>>> >>>>> >>>>> Thanks Scott! >>>>> >>>>> 1. this error is expected: HS 5.2 is not compatible with ORM 5. >>>>> We'll need a compatible WildFly version to release a compatible >>>>> version, or alternatively know how to get the tests to run w/o the >>>>> jipijapa patch as I was trying ;-) >>>> >>>> >>>> >>>> In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, >>>> we >>>> could disable >>>> >>>> org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase >>>> and create a blocking jira for WF10 assigned to you, so you can either >>>> enable the HibernateSearchJPATestCase test or remove Search from WildFly >>>> 10 >>>> as you mention below (as a possible option). Please let me know how you >>>> want me to proceed. >>> >>> >>> That won't be necessary, as a compatible release is now available: >>> update Hibernate Search to version 5.4.0.Alpha1 when you upgrade >>> Hibernate ORM. >>> >>> (don't upgrade HS w/o ORM to 5: it's required for this version of >>> Hibernate Search) >>> >>> Thanks! >>> >>> Sanne

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.

Scott [1] https://github.com/wildfly/wildfly/pull/7509 [2] https://github.com/scottmarlow/wildfly/tree/hibernate5_june18

On 06/18/2015 11:59 AM, Sanne Grinovero wrote: > > On 18 June 2015 at 15:55, Scott Marlow <smarlow(a)redhat.com&gt; 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?

I started with just changing the WildFly (top level) pom.xml to reference HS 5.4.0.Alpha1.

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?

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.

> > 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

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(a)hibernate.org <mailto:sanne@hibernate.org>> wrote: On 18 June 2015 at 17:17, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: > > > On 06/18/2015 11:59 AM, Sanne Grinovero wrote: >> >> On 18 June 2015 at 15:55, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

The ISE message is: " Can not set java.lang.Long field org.jboss.as.test.integration.hibernate.search.Book.id to org.jboss.as.test.integration.hibernate.search.Book ", which does sound like a bug.

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(a)hibernate.org > <mailto:sanne@hibernate.org>> wrote: > > On 18 June 2015 at 17:17, Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@redhat.com>> wrote: > > > > > > On 06/18/2015 11:59 AM, Sanne Grinovero wrote: > >> > >> On 18 June 2015 at 15:55, Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >

On 06/26/2015 12:12 PM, Sanne Grinovero wrote: > On 26 June 2015 at 15:02, Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> The ISE message is: >> " >> Can not set java.lang.Long field >> 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(a)hibernate.org >>> <mailto:sanne@hibernate.org>> wrote: >>> >>> On 18 June 2015 at 17:17, Scott Marlow <smarlow(a)redhat.com >>> <mailto:smarlow@redhat.com>> wrote: >>> > >>> > >>> > On 06/18/2015 11:59 AM, Sanne Grinovero wrote: >>> >> >>> >> On 18 June 2015 at 15:55, Scott Marlow <smarlow(a)redhat.com >>> <mailto:smarlow@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(a)lists.jboss.org <mailto: hibernate-dev(a)lists.jboss.org&gt; >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>

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.

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(a)redhat.com <mailto:smarlow@redhat.com>> wrote: On 06/26/2015 12:12 PM, Sanne Grinovero wrote: > On 26 June 2015 at 15:02, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@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(a)hibernate.org <mailto:sanne@hibernate.org> >>> <mailto:sanne@hibernate.org <mailto:sanne@hibernate.org>>> wrote: >>> >>> On 18 June 2015 at 17:17, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >>> <mailto:smarlow@redhat.com <mailto:smarlow@redhat.com>>> wrote: >>> > >>> > >>> > On 06/18/2015 11:59 AM, Sanne Grinovero wrote: >>> >> >>> >> On 18 June 2015 at 15:55, Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com> >>> <mailto:smarlow@redhat.com <mailto:smarlow@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(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> <mailto:hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>

I tried deploying a simple 2lc enabled test app and got a CNFE on Infinispan classes being referenced from the application classloader. http://pastebin.com/PREzm6bn shows the exception. I'm guessing this is a classloader issue in ORM 5 to be worked out. _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

If Infinispan is not available to core/hem than I am not sure how ORM not being able to find Infinispan classes is a problem with class loading in ORM. Seems to me this is simply a problem in the ClassLoader made available to ORM. On Fri, Jun 19, 2015 at 7:46 AM Scott Marlow <smarlow(a)redhat.com <mailto:smarlow@redhat.com>> wrote: To be a little more specific, WildFly is now respecting the Hibernate Search desire for Infinispan classes to *not* be available to Hibernate core/entitymanager. This is important so that Hibernate Search can have the flexibility to use a different version of Infinispan than WildFly is using with hibernate-infinispan. This seemed to work with Hibernate ORM 4.3.x. On 06/18/2015 04:28 PM, Scott Marlow wrote: > I tried deploying a simple 2lc enabled test app and got a CNFE on > Infinispan classes being referenced from the application classloader. > > http://pastebin.com/PREzm6bn shows the exception. I'm guessing this is > a classloader issue in ORM 5 to be worked out. > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/hibernate-dev

Complete exception call stack is here http://pastebin.com/564BNWSF On 06/19/2015 09:43 AM, Scott Marlow wrote: > I'll see if I can capture a more complete exception call stack for the CNFE. > > On 06/19/2015 09:32 AM, Steve Ebersole wrote: >> If Infinispan is not available to core/hem than I am not sure how ORM >> not being able to find Infinispan classes is a problem with class >> loading in ORM. Seems to me this is simply a problem in the ClassLoader >> made available to ORM. >> >> On Fri, Jun 19, 2015 at 7:46 AM Scott Marlow <smarlow(a)redhat.com >> <mailto:smarlow@redhat.com>> wrote: >> >> To be a little more specific, WildFly is now respecting the Hibernate >> Search desire for Infinispan classes to *not* be available to Hibernate >> core/entitymanager. This is important so that Hibernate Search can have >> the flexibility to use a different version of Infinispan than WildFly is >> using with hibernate-infinispan. This seemed to work with Hibernate ORM >> 4.3.x. >> >> On 06/18/2015 04:28 PM, Scott Marlow wrote: >> > I tried deploying a simple 2lc enabled test app and got a CNFE on >> > Infinispan classes being referenced from the application classloader. >> > >> > http://pastebin.com/PREzm6bn shows the exception. I'm guessing >> this is >> > a classloader issue in ORM 5 to be worked out. >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

2. this is not expected, especially as I think the Infinispan version already in WF is aligned with the one in ORM5? Steve, do you remember about classloader strategy changes between latest ORM 4.3 and 5.0.0.CR1?