Let us know the issue number, so we can link AS7-5511 (AS7 component upgrade to Hibernate 4.1.7.Final) to it. On 09/10/2012 08:33 AM, Emmanuel Bernard wrote:

Hi, On Mon, Sep 10, 2012 at 4:53 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: OK, I'll work on providing a quick start to reproduce the problem. Not sure I'll be able to provide a test without Search though: our application is mostly working except when you have to index an entity. -- Guillaume

I could reproduce the same problem by just running the Hibernate Search testsuite, from master just changing the hibernate-core dependency from 4.1.6 to 4.1.7 The failing test is org.hibernate.search.test.embedded.EmbeddedTest in the "hibernate-search-orm" Maven module, and reproduces exactly the same stacktrace as reported by Guillaume. In this case we are in a "before transaction completion" phase, iterating over a previously non-initialized collection. As you say, it's not finding the CollectionEntry; it would be very nice if you could review your patch using this test to debug? Sanne On 10 September 2012 17:55, Shawn Clowater <shawn.clowater(a)entero.com&gt; wrote:

Spent some time on this. It's not my change, it's the change that allows for collections to be loaded outside of a session. In AbstractPersistentCollection boolean isExtraLazy = withTemporarySessionIfNeeded( new LazyInitializationWork<Boolean>() { @Override public Boolean doWork() { CollectionEntry entry = session.getPersistenceContext().getCollectionEntry( AbstractPersistentCollection.this ); CollectionPersister persister = entry.getLoadedPersister(); if ( persister.isExtraLazy() ) { if ( hasQueuedOperations() ) { session.flush(); } cachedSize = persister.getSize( entry.getLoadedKey(), session ); return true; } else { read(); } return false; } } ); In this case the entry variable ends up being null and then it blows a NPE out of here where it used to blow a LazyInitializationException. Search is checking for that exception to stop processing the collection. AbstractDocumentBuilder, line 285 (in search 4.1.1). It then tries to continue processing and then hits the same type of NPE that the isExtraLazy check was doing. I'm thinking the persistet.isExtraLazy line could be changed to include a null check which would fall into the read() for this case and it would work like it used to since I think you'd also hit this error if you cleared a session and then tried to lazy load a collection. I'll doctor up a test in core and create a JIRA and all of that. Shawn Clowater -----Original Message----- From: hibernate-dev-bounces(a)lists.jboss.org [mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Shawn Clowater Sent: Friday, September 14, 2012 10:23 AM To: Sanne Grinovero Cc: Hibernate Subject: Re: [hibernate-dev] Regression after upgrade to 4.1.7.Final I'm going to be rolling up to 4.1.7 sometime today since we just started our new release and I'm trying to stay as current as I can. I'll see what I can see however, unless the search code is using nested sessions then the patch wouldn't affect it. Since you're already there, can you tell me if it's getting into the beforeTransactionCompletion( transaction ); call in the transactionObserver from SessionImpl. If not, then my patch comment is just a red herring. Shawn Clowater -----Original Message----- From: Sanne Grinovero [mailto:sanne@hibernate.org] Sent: Friday, September 14, 2012 9:56 AM To: Shawn Clowater Cc: Steve Ebersole; Guillaume Smet; Hibernate Subject: Re: [hibernate-dev] Regression after upgrade to 4.1.7.Final I could reproduce the same problem by just running the Hibernate Search testsuite, from master just changing the hibernate-core dependency from 4.1.6 to 4.1.7 The failing test is org.hibernate.search.test.embedded.EmbeddedTest in the "hibernate-search-orm" Maven module, and reproduces exactly the same stacktrace as reported by Guillaume. In this case we are in a "before transaction completion" phase, iterating over a previously non-initialized collection. As you say, it's not finding the CollectionEntry; it would be very nice if you could review your patch using this test to debug? Sanne On 10 September 2012 17:55, Shawn Clowater <shawn.clowater(a)entero.comwrote: a org.hibernate.search.backend.impl.EventSourceTransactionContext$Delegate ToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTra > nsactionContext.java:186) >> at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQ > ueue.beforeTransactionCompletion(ActionQueue.java:662) >> at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQ > ueue.java:307) >> at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionIm > pl.java:607) >> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTra > nsactionCommit(JdbcTransaction.java:105) >> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(Abst > ractTransactionImpl.java:175) >> at > org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:75) >> at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactio > nManager.java:512) >> ... 47 more >> Caused by: java.lang.NullPointerException >> at org.hibernate.engine.internal.StatefulPersistenceContext.getLoadedCollec > tionOwnerOrNull(StatefulPersistenceContext.java:851) >> at org.hibernate.event.spi.AbstractCollectionEvent.getLoadedOwnerOrNull(Abs > tractCollectionEvent.java:75) >> at org.hibernate.event.spi.InitializeCollectionEvent.<init>(InitializeColle > ctionEvent.java:36) >> at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java > :1799) >> at org.hibernate.collection.internal.AbstractPersistentCollection$4.doWork( > AbstractPersistentCollection.java:524) >> at org.hibernate.collection.internal.AbstractPersistentCollection.withTempo > rarySessionIfNeeded(AbstractPersistentCollection.java:212) >> at org.hibernate.collection.internal.AbstractPersistentCollection.initializ > e(AbstractPersistentCollection.java:520) >> at org.hibernate.collection.internal.AbstractPersistentCollection.read(Abst > ractPersistentCollection.java:125) >> at org.hibernate.collection.internal.PersistentBag.iterator(PersistentBag.j > ava:266) >> at org.hibernate.search.engine.spi.AbstractDocumentBuilder.appendContainedI > nWorkForInstance(AbstractDocumentBuilder.java:296) >> at org.hibernate.search.engine.impl.WorkPlan$PerEntityWork.processContained > In(WorkPlan.java:525) >> at org.hibernate.search.engine.impl.WorkPlan$PerClassWork.processContainedI > nAndPrepareExecution(WorkPlan.java:297) >> at org.hibernate.search.engine.impl.WorkPlan.processContainedInAndPrepareEx > ecution(WorkPlan.java:144) >> at org.hibernate.search.backend.impl.WorkQueue.prepareWorkPlan(WorkQueue.ja > va:135) >> at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks( > BatchedQueueingProcessor.java:71) >> at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronizatio > n.beforeCompletion(PostTransactionWorkQueueSynchronization.java:86) >> at org.hibernate.search.backend.impl.EventSourceTransactionContext$Delegate ToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTra > nsactionContext.java:183) >> ... 54 more >>> I don't know if it's something obvious or if you need a self contained >> test case to reproduce it. >>> I haven't created a JIRA because I don't know if it's an >> incompatibility between Hibernate Search 4.1.1 and Hibernate 4.1.7 or >> a real bug (either in HHH or HSEARCH). >>> Feel free to ping me for more information or any further action. >>> Thanks. >> -- > 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 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Thanks Shawn! latest master seems to behave appropriately with the Hibernate Search testsuite after your fix. For the record, this was HHH-7603 Cheers, Sanne On 15 September 2012 20:52, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: