[hibernate-dev] Weird backref issue within the AttributeFactory (Was Re: Some code questions)

[Adam Warski]

In fact I think it's a user-contributed test case.

So damn you users, damn you! ;)

Adam

> OK I've fixed this problem but only to discover another one :(
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4805
> 
> Basically, Adam makes use of generics to declare its components. Since HEM's metamodel generator does not use the XLayer that resolve these generics to their value, a TypeVariable object is returned instead of a Class.
> 
> I'll start working on the conversion to use the XLayer and hope it resolves this problem. But that's probably a longer process.
> 
> Damn you Adam, damn you!
> 
> On 14 janv. 2010, at 15:35, Steve Ebersole wrote:
> 
>> Ah, backrefs!
>> 
>> Just disregarding them makes the most sense for sure from the JPA
>> perspective since they are "virtual attributes" and solely a hibernate
>> construct.
>> 
>> On Thu, 2010-01-14 at 11:29 +0100, Emmanuel Bernard wrote:
>>> On 13 janv. 2010, at 20:37, Hardy Ferentschik wrote:
>>>> I have a couple of question regarding some recent code changes. The first one seems to be the cause of a
>>>> test failure in VersionsJoinTableRangeComponentNamingTest (Envers). It actually causes a NullPointerException.
>>>> Have a look at: http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main/java/org/hibernate/cfg/AbstractPropertyHolder.java?r=18518#l254
>>> 
>>> Right, I fixed the problem, sorry about that.
>>> Though it uncovered a weird problem.
>>> When I run the entire envers test suite, I pass with flags up.
>>> When I specifically run VersionsJoinTableRangeComponentNamingTest
>>> I've got a 
>>> java.lang.IllegalArgumentException: Cannot determine java-type from given member [null]
>>> 	at org.hibernate.ejb.metamodel.AttributeFactory$BaseAttributeMetadata.<init>(AttributeFactory.java:591)
>>> 	at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:671)
>>> 	at org.hibernate.ejb.metamodel.AttributeFactory$SingularAttributeMetadataImpl.<init>(AttributeFactory.java:661)
>>> 	at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:542)
>>> 	at org.hibernate.ejb.metamodel.AttributeFactory.buildAttribute(AttributeFactory.java:81)
>>> 	at org.hibernate.ejb.metamodel.MetadataContext.wrapUp(MetadataContext.java:177)
>>> 	at org.hibernate.ejb.metamodel.MetamodelImpl.buildMetamodel(MetamodelImpl.java:66)
>>> 	at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:79)
>>> 	at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:752)
>>> 	at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:94)
>>> 	at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:82)
>>> 
>>> The member is null because the "property" has a backref getter and hence no member is returned by NORMAL_MEMBER_RESOLVER. I think we should ignore backref properties
>>> 
>>> Does that make sense? If we agree, I will go and apply a fix.
>>> 
>>> http://opensource.atlassian.com/projects/hibernate/browse/HHH-4797
>>> 
>>> 
>>>> 
>>>> 
>>>> Also have a look at http://fisheye.jboss.org/browse/Hibernate/core/trunk/annotations/src/main/java/org/hibernate/cfg/AnnotationConfiguration.java?r=18506#l896
>>>> You create a AssertionFailure, but then don't throw it? I guess this is just missing a 'throw' before the new.
>>> 
>>> yep, fixed.
>> -- 
>> Steve Ebersole <steve at hibernate.org>
>> Hibernate.org
>> 
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev