NaturalIdXrefDelegate key comparison issue
by Eric Dalquist
I haven't spent a ton of time looking into this yet but while trying to
update uPortal to use naturalIds in 4.1.1 I think I ran into a bug in:
NaturalIdXrefDelegate$NaturalIdResolutionCache.areSame(Object[], Object[])
That code uses Type.compare(Object x, Object y) to compare each pair of
fields in the two naturalIds.
I have an entity that has a field of type Class which ends up using the
org.hibernate.type.ClassType.
ClassType relies on parent class AbstractStandardBasicType to implement
the compare method.
AbstractStandardBasicType uses the JavaTypeDescriptor.getComparator()
method to get the comparator to use.
For ClassType the JavaTypeDescriptor is
org.hibernate.type.descriptor.java.ClassTypeDescriptor which never sets
a comparator so JavaTypeDescriptor.getComparator() returns null
resulting in the following NPE:
Caused by: java.lang.NullPointerException
at
org.hibernate.type.AbstractStandardBasicType.compare(AbstractStandardBasicType.java:210)
at
org.hibernate.engine.internal.NaturalIdXrefDelegate$NaturalIdResolutionCache.areSame(NaturalIdXrefDelegate.java:353)
at
org.hibernate.engine.internal.NaturalIdXrefDelegate$NaturalIdResolutionCache.cache(NaturalIdXrefDelegate.java:338)
at
org.hibernate.engine.internal.NaturalIdXrefDelegate.cacheNaturalIdResolution(NaturalIdXrefDelegate.java:78)
at
org.hibernate.engine.internal.StatefulPersistenceContext.entityStateUpdatedNotification(StatefulPersistenceContext.java:1732)
at
org.hibernate.engine.spi.EntityEntry.notifyLoadedStateUpdated(EntityEntry.java:382)
at
org.hibernate.engine.spi.EntityEntry.postUpdate(EntityEntry.java:244)
at
org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:152)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at
org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:276)
at
org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
at
org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
at
org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325)
at
org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
at
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73)
I likely won't have time to try and reproduce this in a hibernate unit
test until Monday or Tuesday, I'm hoping someone might have a quick insight.
-Eric
12 years, 9 months
Micro Jiras
by Hardy Ferentschik
Hi,
I noticed that recently we create a lot of "micro" jira issues (just as an example "missing ; in class xyz").
Most issues are related to the current metamodel work. I am wondering how useful that is?
The metamodel is under heavy development and I think liras should stay on a functional level,
eg "Implement collection binding", etc. Imagine what's going to happen once we start running the existing
integration tests against the new metamodel. We will have to change things left, right and center. Does it make
sense to create Jira issues for each change? I don't think so.
Also, Jira is not only used by us, but also by our users. They see the resolved Jiras in the change log
and they also use Jira to find out whether bugs see experience are already reported. Having all these
micro issues does make this harder imo.
Is it just me feeling this way?
--Hardy
12 years, 9 months
immutable can be deleted? and should readonly cache throw exception?
by Strong Liu
Hi There,
is an immutable entity can be deleted?
according to http://docs.jboss.org/hibernate/core/4.0/manual/en-US/html_single/
"12.1.1. Entities of immutable classes"
"An entity of an immutable class can created and deleted the same as an entity of a mutable class."
but "5.1.1 Entity" saying:
"Some entities are not mutable. They cannot be updated or deleted by the application. This allows Hibernate to make some minor performance optimizations.. Use the @Immutable annotation."
the reason i'm asking this is this test org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest#testPolymorphism.
when running testsuite on jdk 7, the order of methods returned by getDeclaredMethods changed and can vary from run to run (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7023180), so, the order of each test case in a test class can't be guaranteed.
so, we need each test case independent.
clearly, this test case depends on the order.
I added a cleanupTest method
@Override
protected void cleanupTest() throws Exception {
Session s = openSession();
s.beginTransaction();
List list = s.createQuery( "from java.lang.Object" ).list();
for(Object obj : list){
s.delete( obj );
}
s.getTransaction().commit();
s.close();
}
and get this exception:
java.lang.UnsupportedOperationException: Can't write to a readonly object
at org.hibernate.testing.cache.ReadOnlyEntityRegionAccessStrategy.lockItem(ReadOnlyEntityRegionAccessStrategy.java:68)
at org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:84)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:280)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127)
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
at org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest.cleanupTest(BasicHibernateAnnotationsTest.java:105)
btw, i'm also seeing this jira https://hibernate.onjira.com/browse/HHH-6329
change the cleanupTest to use hql (s.createQuery("delete java.lang.Object").executeUpdate();) runs successfully and no test failure.
-------------------------
Best Regards,u
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
12 years, 9 months
testJGroupsBackend fail
by Nicolas Helleringer
On current master state I got a :
Results :
Failed tests:
testJGroupsBackend(org.hibernate.search.test.jgroups.common.JGroupsCommonTest):
expected:<1> but was:<0>
Tests run: 457, Failures: 1, Errors: 0, Skipped: 1
I am on windows. Any ideas ?
Cheers,
Niko
12 years, 9 months
Re: [hibernate-dev] Hibernate ORM 4.1.1 release - Undocumented behavior change in Optimistic Versioning ?
by Demetz, Guenther
Hi hibernate developers,
testing Hibernate ORM 4.1.1 I discovered a behavior change regarding Optimistic Lock Versioning
in detail on bidirectional OneToMany relations with inverse-owner (mappedBy attribute specified):
- until Hiberante version 4.1.0 by default on changes both involved sides got a version increment
- now with Hiberante4.1.1 only the owner-side (=the Many-side) gets a version increment.
To make the thing working as before,
now on such relations we must define explicitly OptimisticLock.excluded=false
@javax.persistence.OneToMany(mappedBy = "parent")
@org.hibernate.annotations.OptimisticLock(excluded=false)
@javax.persistence.MapKey(name="field1")
private Map<String,Child> aggChild = new java.util.HashMap();
Was such behavior change intended?
I looked at the 28 issues which had been fixed with Hiberante4.1.1 but found nothing in regard,
maybe I overlooked something ?
Würth Phoenix S.r.l.
Günther Demetz
Via Kravogl 4
I-39100 Bolzano
E-Mail: guenther.demetz(a)wuerth-phoenix.com
Website: www.wuerth-phoenix.com
12 years, 9 months
Hibernate OGM#OGM-123 Add Voldemort Datastore
by Seiya Kawashima
Hi,
I've just found the task and was wondering if I can be assigned on this
task. I would like to finish the task based on the comments that I got and
will get for my pull request if it's possible.
--
Thank you
Seiya
12 years, 9 months
Re: [hibernate-dev] Infinispan tests
by Steve Ebersole
Well I recently just "upgraded" to Fedora 14 so that may very well have
something to do with it. The hibernate-infinispan tests always ran slow,
but this 56 minutes number is a whole new level of frustration ;)
steve(a)hibernate.org
http://hibernate.org
On Mar 8, 2012 9:54 AM, "Sanne Grinovero" <sanne(a)infinispan.org> wrote:
> Time to get a new box?
>
> Total time: 5 mins 20.498 secs
>
> Jokes aside, maybe some system setting is wrong; to run the Infinispan
> testsuite we need some system level settings, like
> https://issues.jboss.org/browse/ISPN-1890
> and lots of memory help as well; maybe there is a wrong network
> configuration: if you happen to have packets sent out to a - for
> example - wifi router, have a sightseeing tour around your home
> devices and back, that will be much slower than localhost connections.
> I don't know if this is required for the Infinispan tests in Hibernate
> as well, but maybe it affects performance.
>
> --Sanne
>
>
> On 8 March 2012 15:42, Steve Ebersole <steve(a)hibernate.org> wrote:
> > 11 minutes?!?! I had to kill the one last night and just disable those
> > tests for the release. This morning I let it run. 56 minutes. Yep
> > 56! And thats solely for running the hibernate-infinispan tests.
> > Everything else was built already.
> >
> >
> > [steve@apollo hibernate-infinispan]$ gradle clean test
> > :buildSrc:compileJava UP-TO-DATE
> > :buildSrc:compileGroovy UP-TO-DATE
> > :buildSrc:processResources UP-TO-DATE
> > :buildSrc:classes UP-TO-DATE
> > :buildSrc:jar UP-TO-DATE
> > :buildSrc:assemble UP-TO-DATE
> > :buildSrc:compileTestJava UP-TO-DATE
> > :buildSrc:compileTestGroovy UP-TO-DATE
> > :buildSrc:processTestResources UP-TO-DATE
> > :buildSrc:testClasses UP-TO-DATE
> > :buildSrc:test UP-TO-DATE
> > :buildSrc:check UP-TO-DATE
> > :buildSrc:build UP-TO-DATE
> > The Configuration.addDependency() method has been deprecated and will be
> > removed in the next version of Gradle. Please use the
> > getDependencies().add() method instead.
> > The SourceSet.getClasses() method has been deprecated and will be
> > removed in the next version of Gradle. Please use the getOutput() method
> > instead.
> > The SourceSet.getClassesDir() method has been deprecated and will be
> > removed in the next version of Gradle. Please use the
> > getOutput().getClassesDir() method instead.
> > The SourceSet.setClassesDir() method has been deprecated and will be
> > removed in the next version of Gradle. Please use the
> > getOutput().setClassesDir() method instead.
> > The Configuration.getAllArtifactFiles() method has been deprecated and
> > will be removed in the next version of Gradle. Please use the
> > getAllArtifacts().getFiles() method instead.
> > :hibernate-infinispan:clean
> > > Building > :hibernate-core:generateGrammarSource > Resolving
> > dependencies ':hibernate-core:hibernate-core:generateGrammarSource
> > UP-TO-DATE
> > :hibernate-core:jaxb UP-TO-DATE
> > > Building > :hibernate-core:generateMainLoggingClasses > Resolving
> > dependencies ':hibernate:hibernate-core:generateMainLoggingClasses
> > UP-TO-DATE
> > :hibernate-core:compileJava UP-TO-DATE
> > :hibernate-core:processResources UP-TO-DATE
> > :hibernate-core:classes UP-TO-DATE
> > :hibernate-core:jar UP-TO-DATE
> > > Building > :hibernate-infinispan:generateMainLoggingClasses >
> > Resolving dependencies
> > ':hib:hibernate-infinispan:generateMainLoggingClasses
> > :hibernate-infinispan:compileJava
> > [ant:javac] Note: Some input files use or override a deprecated API.
> > [ant:javac] Note: Recompile with -Xlint:deprecation for details.
> > [ant:javac] Note: Some input files use unchecked or unsafe operations.
> > [ant:javac] Note: Recompile with -Xlint:unchecked for details.
> > :hibernate-infinispan:processResources
> > :hibernate-infinispan:classes
> > > Building > :hibernate-testing:generateMainLoggingClasses > Resolving
> > dependencies ':hibern:hibernate-testing:generateMainLoggingClasses
> > :hibernate-testing:compileJava
> > [ant:javac] Note: Some input files use unchecked or unsafe operations.
> > [ant:javac] Note: Recompile with -Xlint:unchecked for details.
> > :hibernate-testing:processResources UP-TO-DATE
> > :hibernate-testing:classes
> > :hibernate-testing:jar
> > > Building > :hibernate-infinispan:compileTestJava > Resolving
> > dependencies ':hibernate-infi:hibernate-infinispan:compileTestJava
> > [ant:javac] Note: Some input files use or override a deprecated API.
> > [ant:javac] Note: Recompile with -Xlint:deprecation for details.
> > [ant:javac] Note: Some input files use unchecked or unsafe operations.
> > [ant:javac] Note: Recompile with -Xlint:unchecked for details.
> > :hibernate-infinispan:processTestResources
> > :hibernate-infinispan:testClasses
> > > Building > :hibernate-infinispan:test > Resolving dependencies
> > ':hibernate-infinispan:test:hibernate-infinispan:test
> >
> > BUILD SUCCESSFUL
> >
> > Total time: 56 mins 36.254 secs
> >
> > On 03/08/2012 04:34 AM, Hardy Ferentschik wrote:
> >> Hi,
> >>
> >> it just took 5 attempts to build everything :-(
> >>
> >> The first two times I got errors due to unresolved dependencies (first
> time some docbook stuff, then Infinispan).
> >> In both cases the problem went away by restarting the build.
> >>
> >> The third time around I got a test failure in
> org.hibernate.test.annotations.onetoone.OneToOneTest. No idea why.
> >>
> >> The forth time around
> org.hibernate.envers.test.integration.components.PropertiesGroupTest failed.
> >> I've seen this test fail before (also on the metamodel branch I
> believe). Does anyone else see this test fail at times?
> >>
> >> The fifth time the build completed successfully. I can confirm that the
> infinispan module creates some artifacts outside
> >> of the build directory ObjectStore and PutObjectStoreDirHere. I don't
> think the tests ran any slower than they used to.
> >>
> >> Total build time for me (according to gradle) was 11 mins 1.78 secs
> >>
> >> I find the "random" test errors worrying though. Anyone experiencing
> them as well?
> >>
> >> --Hardy
> >>
> >>
> >> On Mar 8, 2012, at 3:56 AM, Steve Ebersole wrote:
> >>
> >>> Hmm, I did not have problems resolving artifacts, but I just noticed
> >>> this CR... we really need to not be upgrading to CR releases of
> >>> dependencies as part of a point release. Sigh
> >>>
> >>> On Wed 07 Mar 2012 08:19:55 PM CST, Strong Liu wrote:
> >>>> btw ci fails due to
> >>>>
> >>>> 08:23:54.474 [ERROR] [org.gradle.BuildExceptionReporter] Could not
> >>>> resolve all dependencies for configuration
> >>>> ':hibernate-infinispan:testCompile'.
> >>>> 08:23:54.478 [ERROR] [org.gradle.BuildExceptionReporter]> Artifact
> 'org.infinispan:infinispan-core:5.1.2.CR1:tests@jar' not found.
> >>>>
> >>>> -------------------------
> >>>> Best Regards,
> >>>>
> >>>> Strong Liu<stliu at hibernate.org<http://hibernate.org/>>
> >>>> http://about.me/stliu/bio
> >>>>
> >>>> On Mar 8, 2012, at 10:04 AM, Steve Ebersole wrote:
> >>>>
> >>>>> Speaking of which, is everyone else seeing tests in
> >>>>> hibernate-infinispan taking many many minutes to run?
> >>>>
> >>>> yes, it reallly takes some time
> >>>>
> >>>>> On Wed 07 Mar 2012 07:53:42 PM CST, Steve Ebersole wrote:
> >>>>>> Running the hibernate-infinispan tests I am seeing 2 output
> >>>>>> directories showing up in the hibernate-infinispan directory (aka,
> not
> >>>>>> hibernate-infinispan/target/...). Namely, I see
> >>>>>> hibernate-infinispan/ObjectStore and
> >>>>>> hibernate-infinispan/PutObjectStoreDirHere. Anyone know how/if we
> can
> >>>>>> change where those directories get created?
> >>>>>>
> >>>>> --
> >>>>> steve(a)hibernate.org<mailto:steve@hibernate.org>
> >>>>> http://hibernate.org
> >>>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev(a)lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> --
> >>> steve(a)hibernate.org
> >>> http://hibernate.org
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >> --
> >> steve(a)hibernate.org
> >> http://hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
12 years, 9 months
release
by Steve Ebersole
Just a heads up that I cut the release and pushed bundles to SF and
artifacts to Nexus. I'll upload docs and blog tomorrow.
Can anyone point me to the definitive page detailing docs.jboss.org
access? Thanks.
--
steve(a)hibernate.org
http://hibernate.org
12 years, 9 months
