Well that's Christmas before time.
I think it fixes it properly. I forgot that the unproxy method was returning
the wrapped object.
On 1 déc. 2010, at 12:08, Sanne Grinovero wrote:
> Emmanuel,
> now I'm failing org.hibernate.search.test.proxy.ProxyTest.testDeteleProxy()
> as it actually succedes
Emmanuel,
now I'm failing org.hibernate.search.test.proxy.ProxyTest.testDeteleProxy()
as it actually succedes but it is annotated as
@FailureExpected(jiraKey = "HSEARCH-577")
so it seems I've actually fixed the non-resolved HSEARCH-577, is
that a correct interpretation of this unit test?
Sanne
thank you, "unproxy" worked great. Not sure why it wasn't there
already as I didn't change this area, apparently it was unlikely to
receive a proxy in this method.
Sanne
2010/12/1 Emmanuel Bernard :
> This exception in general can have a bunch of causes.
>
> In you case though, in Hibernate Search
This exception in general can have a bunch of causes.
In you case though, in Hibernate Search there are several tools at your
disposal. All in HibernateHelper.
For the most part they abstract away Hibernate calls for when we will make
Hibernate Search fully independent of Hibernate Core.
unprox
Hello,
I'm blocked by the exception mentioned in the subject, this is also
affecting my work in Search:
with the new design I need the object identifier more often than before, and
even our own org.hibernate.search.test.proxy.ProxyTest fails.
Searching for similar exceptions I found many users ask
