9:49 a.m.
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(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
>>>
>>