11:29 a.m.
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...
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...
You create a AssertionFailure, but then don't throw it? I guess this is just missing
a 'throw' before the new.
yep, fixed.
1:54 p.m.
We disabled the test yesterday in order to do the release.
It was failing in w/ and w/o a fix to Emmanuel's code.
--Hardy
On Thu, 14 Jan 2010 09:24:23 -0300, Adam Warski <adam(a)warski.org> wrote:
Hello,
> Though it uncovered a weird problem.
> When I run the entire envers test suite, I pass with flags up.
> When I specifically run VersionsJoinTableRangeComponentNamingTest
That's probably because the test is disabled in the suite :).
1:57 p.m.
Right, I tried to explain the failure in the first email. But AFAIK the bug has been there
for a little while (ie before the work i've done in the last couple of days).
On 14 janv. 2010, at 13:54, Hardy Ferentschik wrote:
We disabled the test yesterday in order to do the release.
It was failing in w/ and w/o a fix to Emmanuel's code.
--Hardy
On Thu, 14 Jan 2010 09:24:23 -0300, Adam Warski <adam(a)warski.org> wrote:
> Hello,
>
>> Though it uncovered a weird problem.
>> When I run the entire envers test suite, I pass with flags up.
>> When I specifically run VersionsJoinTableRangeComponentNamingTest
>
> That's probably because the test is disabled in the suite :).
>
2:04 p.m.
Hello,
Right, I tried to explain the failure in the first email. But AFAIK
the bug has been there for a little while (ie before the work i've done in the last
couple of days).
yes, it's there for at least two weeks. I mentioned it on IRC before but I guess it
didn't draw any attention.
I didn't create a JIRA issue as it's in the new metamodel stuff so I figured that
you're actively working on it. But at least it serves as a good testcase for it :)
--
Adam
3:35 p.m.
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...
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...
> 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(a)hibernate.org>
Hibernate.org
11:54 a.m.
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...
>
> 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...
>> 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(a)hibernate.org>
Hibernate.org
1:23 p.m.
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...
>>
>> 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...
>>> 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(a)hibernate.org>
> Hibernate.org
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:51 p.m.
So after chasing bugs after bugs for 25 generations, I've got something that does not
cover all cases (that are not within JPA's boundaries anyway) but at least that does
not throw weird exceptions. To test it, you need to get the latest trunk of HEM and use
the latest published snapshot of the static metamodel generator (jpamodelgen).
However, the Envers test still fails VersionsJoinTableRangeComponentNamingTest but with a
query exception. And I am seriously doubting the validity of this test in the first place.
Has it ever pass? Is it valid?
Adam, can you check it out and give us more feedback?
19:36:42,066 WARN JDBCExceptionReporter:100 - SQL Error: -28, SQLState: S0022
19:36:42,066 ERROR JDBCExceptionReporter:101 - Column not found: VJTRCTE1_ID in statement
[select join_table0_.REV as col_0_0_, join_table0_.VJTRCTE1_ID as col_0_1_,
join_table0_.VJTRTE_ID as col_0_2_, versionsjo1_.id as col_1_0_, versionsjo1_.REV as
col_1_1_ from JOIN_TABLE_COMPONENT_1_AUD join_table0_ cross join RANGE_TEST_ENTITY_AUD
versionsjo1_ where join_table0_.VJTRTE_ID=versionsjo1_.id and join_table0_.VJTRCTE1_ID=?
and (versionsjo1_.REV in (select max(versionsjo2_.REV) from RANGE_TEST_ENTITY_AUD
versionsjo2_ where versionsjo2_.REV<=? and versionsjo1_.id=versionsjo2_.id)) and
join_table0_.REV=(select max(join_table3_.REV) from JOIN_TABLE_COMPONENT_1_AUD
join_table3_ where join_table3_.REV<=? and
join_table0_.VJTRCTE1_ID=join_table3_.VJTRCTE1_ID and
join_table0_.VJTRTE_ID=join_table3_.VJTRTE_ID) and join_table0_.REVTYPE<>? and
versionsjo1_.REVTYPE<>?]
org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.loader.Loader.doList(Loader.java:2235)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2129)
at org.hibernate.loader.Loader.list(Loader.java:2124)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:416)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1258)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at
org.hibernate.envers.entities.mapper.relation.lazy.initializor.AbstractCollectionInitializor.initialize(AbstractCollectionInitializor.java:62)
at
org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.checkInit(CollectionProxy.java:50)
at
org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.size(CollectionProxy.java:55)
at
org.hibernate.envers.test.integration.naming.VersionsJoinTableRangeComponentNamingTest.testHistoryOfUniId1(VersionsJoinTableRangeComponentNamingTest.java:165)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:607)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:517)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:669)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:956)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110)
at org.testng.TestRunner.runWorkers(TestRunner.java:759)
at org.testng.TestRunner.privateRun(TestRunner.java:592)
at org.testng.TestRunner.run(TestRunner.java:486)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
at org.testng.SuiteRunner.run(SuiteRunner.java:204)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:867)
at org.testng.TestNG.runSuitesLocally(TestNG.java:832)
at org.testng.TestNG.run(TestNG.java:748)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:79)
Caused by: java.sql.SQLException: Column not found: VJTRCTE1_ID in statement [select
join_table0_.REV as col_0_0_, join_table0_.VJTRCTE1_ID as col_0_1_, join_table0_.VJTRTE_ID
as col_0_2_, versionsjo1_.id as col_1_0_, versionsjo1_.REV as col_1_1_ from
JOIN_TABLE_COMPONENT_1_AUD join_table0_ cross join RANGE_TEST_ENTITY_AUD versionsjo1_
where join_table0_.VJTRTE_ID=versionsjo1_.id and join_table0_.VJTRCTE1_ID=? and
(versionsjo1_.REV in (select max(versionsjo2_.REV) from RANGE_TEST_ENTITY_AUD versionsjo2_
where versionsjo2_.REV<=? and versionsjo1_.id=versionsjo2_.id)) and
join_table0_.REV=(select max(join_table3_.REV) from JOIN_TABLE_COMPONENT_1_AUD
join_table3_ where join_table3_.REV<=? and
join_table0_.VJTRCTE1_ID=join_table3_.VJTRCTE1_ID and
join_table0_.VJTRTE_ID=join_table3_.VJTRTE_ID) and join_table0_.REVTYPE<>? and
versionsjo1_.REVTYPE<>?]
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.executeQuery(Unknown Source)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1810)
at org.hibernate.loader.Loader.doQuery(Loader.java:697)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
at org.hibernate.loader.Loader.doList(Loader.java:2232)
... 33 more
On 15 janv. 2010, at 13:23, Adam Warski wrote:
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...
>>>
>>> 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...
>>>> 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(a)hibernate.org>
>> Hibernate.org
>>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:56 a.m.
Hello,
So after chasing bugs after bugs for 25 generations, I've got
something that does not cover all cases (that are not within JPA's boundaries anyway)
but at least that does not throw weird exceptions. To test it, you need to get the latest
trunk of HEM and use the latest published snapshot of the static metamodel generator
(jpamodelgen).
You must like me even more then ;)
However, the Envers test still fails
VersionsJoinTableRangeComponentNamingTest but with a query exception. And I am seriously
doubting the validity of this test in the first place. Has it ever pass? Is it valid?
Yes, I'm sure it passed in trunk on 18th Dec (as all other tests), and it also
passes on the hibernate-3.3 branch.
I also just updated trunk to latest, re-built everything a ran all tests and they all
passed. Also running the VersionsJoinTableRangeComponentNamingTest test explicitly works:
mvn -Dtest=VersionsJoinTableRangeComponentNamingTest clean test
(...)
Results :
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
--
Adam
5221
days inactive
5223
days old
10 comments
4 participants
participants (4)
-
Adam Warski -
Emmanuel Bernard -
Hardy Ferentschik -
Steve Ebersole