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 <st...@hibernate.org> >> Hibernate.org >> > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
