Class not found: ReflectionManager

[bwallis42]

I have been porting an app from modeshape 2.8/Jboss as6 to modeshape 3.0.0/jboss as7.1.2

It is mostly working now but I am getting the following warning for a class not found.

As far as I can tell the class is available from the hibernate module. Anyone seen this or have an idea what might be the cause?

thanks

{noformat}
17:47:57,573 WARN  [com.arjuna.ats.arjuna] (MSC service thread 1-8) ARJUNA012129: TwoPhaseCoordinator.afterCompletion - failed for SynchronizationImple< 0:ffff0a40213d:-160d02ab:4fe02e9d:a, org.modeshape.jcr.txn.SynchronizedTransactions$SynchronizedTransaction$1@5f91e550 > with error: java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/ReflectionManager
          at org.modeshape.jcr.RepositoryQueryManager.queryEngine(RepositoryQueryManager.java:125) [modeshape-jcr-3.0.0.Alpha5.jar:3.0.0.Alpha5]
          at org.modeshape.jcr.RepositoryQueryManager.getIndexes(RepositoryQueryManager.java:112) [modeshape-jcr-3.0.0.Alpha5.jar:3.0.0.Alpha5]
          at org.modeshape.jcr.JcrRepository$RepositoryMonitorFactory.createMonitor(JcrRepository.java:1633) [modeshape-jcr-3.0.0.Alpha5.jar:3.0.0.Alpha5]
          at org.modeshape.jcr.txn.Transactions.newMonitor(Transactions.java:175) [modeshape-jcr-3.0.0.Alpha5.jar:3.0.0.Alpha5]
          at org.modeshape.jcr.txn.SynchronizedTransactions$SynchronizedTransaction.afterCommit(SynchronizedTransactions.java:165) [modeshape-jcr-3.0.0.Alpha5.jar:3.0.0.Alpha5]
          at org.modeshape.jcr.txn.SynchronizedTransactions$SynchronizedTransaction$1.afterCompletion(SynchronizedTransactions.java:124) [modeshape-jcr-3.0.0.Alpha5.jar:3.0.0.Alpha5]
          at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
          at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402)
          at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:103)
          at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
          at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
          at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
          at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:231) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:332) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:57) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
          at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
          at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
          at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:119) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:134) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
          at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
          at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
          at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_33]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_33]
          at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_33]
Caused by: java.lang.ClassNotFoundException: org.hibernate.annotations.common.reflection.ReflectionManager from [Module "org.hibernate.search-engine:4.1" from local module loader @4476128 (roots: /Users/bwallis/InfoMedix/Harvey/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)]
          at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
          at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
          at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
          ... 33 more
{noformat}

[rhauch]

I wish there were more to that stack trace. I'd love to know what's trying to use reflection; we've already corrected a few issues in Hibernate Search that don't work with AS7's modular classloaders. I wonder if this is another one. Any chance you could find out more about where that call is coming from?

It looks like you're installing to an Alpha snapshot of AS 7.2.0? I haven't had a chance to do this yet, but we're going to want to get ModeShape working on that pretty quickly, since it has a lot of fixes in AS7 and in the way Infinispan works. For example, there's a new "module" attribute on the cacheContainer element in the Infinispan subsystem, and this can be set to "org.modeshape" so that Infinispan can find our SchematicEntryValue class (which is what we're storing as values inside Infinispan).

[bwallis42]

Immediately prior to the stack trace is the following logging (should have included it before)

{noformat}
17:47:57,474 FINE  [org.modeshape.jcr.RepositoryQueryManager] (MSC service thread 1-8) Hibernate Search configuration for repository 'DocumentStore': hibernate.search.worker.thread_pool.size = 1
hibernate.search.lucene_version = LUCENE_CURRENT
hibernate.search.reader.strategy = shared
hibernate.search.similarity = org.apache.lucene.search.DefaultSimilarity
hibernate.search.default.worker.backend = lucene
hibernate.search.default.filesystem_access_type = auto
hibernate.search.default.indexBase = /Users/bwallis/InfoMedix/Harvey/jboss-as-7.2.0.Alpha1-SNAPSHOT/standalone/data/modeshape/DocumentStore/DocumentStore/indexes
hibernate.search.worker.buffer_queue.max = 1
hibernate.search.worker.execution = sync
hibernate.search.worker.batch_size = -1
hibernate.search.default.locking_strategy = native
hibernate.search.default.directory_provider = filesystem
{noformat}

Means nothing to me but might be relevant.

I am using a jboss 7.2.0 (corrected version number) snapshot as I have come across some of the issues in 7.1.1. It hasn't (so far) given me any problems.

I sort of expect it is close to release, maybe around the 26th at about the same time as jboss world in Boston? :-)

thanks

[rhauch]

The logging just shows the Hibernate Search configuration that we're generating. When I said "more about where that call is coming from", I actually meant it'd be really helpful to know what was truncated from this part of the stack trace:

Caused by: java.lang.ClassNotFoundException: org.hibernate.annotations.common.reflection.ReflectionManager from [Module "org.hibernate.search-engine:4.1" from local module loader @4476128 (roots: /Users/bwallis/InfoMedix/Harvey/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)]

          at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)

          at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)

          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)

          at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)

          at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)

          at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)

          ... 33 more

The "ReflectionManager" class is used within Hibernate Search, and it's the classloader for the Hibernate Search module that is trying to load it. But the ReflectionManager is actually in the "org.hibernate:main" module (in the "hibernate-commons-annotations-4.0.1.Final.jar" file).

After looking at the code, I noticed that ModeShape code is importing and using this. So try editing the "modules/org/hibernate/search-engine/4.1/module.xml" file and changing this line:

        <module name="org.hibernate"/>

to this:

        <module name="org.hibernate" export="true"/>

Hopefully that works. If that doesn't, perhaps this dependency needs to be added to the "modules/org/modeshape/main/module.xml" file. Please let us know!

BTW, I'm glad to hear that you're having no issues with AS7.2. I very much am interested in jumping to this as soon as we can, because it should include Infinispan 5.2.x plus have a number of integration issues fixed. As for the timing of 7.2 release, I can't say -- other than I hope it is as soon as possible!

[bwallis42]

Tried the export on the module line but I get the same error.

{code}
<module xmlns="urn:jboss:module:1.1" name="org.hibernate.search-engine" slot="4.1">
    <resources>
        <resource-root path="hibernate-search-engine-4.1.1.Final.jar" />
        <resource-root path="hibernate-search-infinispan-4.1.1.Final.jar" />
        <resource-root path="infinispan-lucene-directory-5.1.2.FINAL.jar" />
        <resource-root path="avro-1.5.1.jar" />
        <resource-root path="jackson-mapper-asl-1.9.2.jar" />
        <resource-root path="jackson-core-asl-1.9.2.jar" />
        <resource-root path="paranamer-2.3.jar" />
        <resource-root path="snappy-java-1.0.1-rc3.jar" />
    </resources>
    <dependencies>
        <module name="javax.transaction.api"/>
        <module name="org.hibernate" export="true"/>
        <module name="org.apache.lucene" export="true" slot="3.5"/>
        <module name="org.jboss.logging" />
        <module name="org.jgroups" />
        <module name="org.infinispan" />
        <!-- For naming (used by Hibernate Search Infinispan)... -->
        <module name="javax.api"/>
        <module name="org.jboss.as.naming"/>
    </dependencies>
</module>
{code}

I set a breakpoint and captured the rest of the stack trace

{noformat}
Thread [MSC service thread 1-2] (Suspended (exception ClassNotFoundException))
        ModuleClassLoader.findClass(String, boolean, boolean) line: 190 
        ModuleClassLoader(ConcurrentClassLoader).performLoadClassUnchecked(String, boolean, boolean) line: 468  
        ModuleClassLoader(ConcurrentClassLoader).performLoadClassChecked(String, boolean, boolean) line: 456
        ModuleClassLoader(ConcurrentClassLoader).performLoadClassChecked(String, boolean, boolean) line: 423    
        ModuleClassLoader(ConcurrentClassLoader).performLoadClass(String, boolean, boolean) line: 398
        ModuleClassLoader(ConcurrentClassLoader).loadClass(String) line: 120    
        RepositoryQueryManager.queryEngine() line: 125  
        RepositoryQueryManager.getIndexes() line: 112   
        JcrRepository$RepositoryMonitorFactory.createMonitor() line: 1633
        SynchronizedTransactions(Transactions).newMonitor() line: 175   
        SynchronizedTransactions$SynchronizedTransaction.afterCommit() line: 165        
        SynchronizedTransactions$SynchronizedTransaction$1.afterCompletion(int) line: 124       
        SynchronizationImple.afterCompletion(int) line: 96
        AtomicAction(TwoPhaseCoordinator).afterCompletion(int, boolean) line: 402       
        AtomicAction(TwoPhaseCoordinator).end(boolean) line: 103        
        AtomicAction(AtomicAction).commit(boolean) line: 164    
        TransactionImple.commitAndDisassociate() line: 1165
        TransactionManagerImple(BaseTransaction).commit() line: 117     
        TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 75    
        SingletonLifecycleCMTTxInterceptor(CMTTxInterceptor).endTransaction(TransactionManager, Transaction) line: 91
        SingletonLifecycleCMTTxInterceptor(CMTTxInterceptor).invokeInOurTx(InterceptorContext, TransactionManager, EJBComponent) line: 231      
        SingletonLifecycleCMTTxInterceptor(CMTTxInterceptor).requiresNew(InterceptorContext, EJBComponent, int) line: 332
        SingletonLifecycleCMTTxInterceptor.processInvocation(InterceptorContext) line: 57       
        InterceptorContext.proceed() line: 288  
        CurrentInvocationContextInterceptor.processInvocation(InterceptorContext) line: 41      
        InterceptorContext.proceed() line: 288
        TCCLInterceptor.processInvocation(InterceptorContext) line: 45  
        InterceptorContext.proceed() line: 288  
        ChainedInterceptor.processInvocation(InterceptorContext) line: 61       
        SingletonComponent(BasicComponent).constructComponentInstance(ManagedReference, boolean, InterceptorFactoryContext) line: 161
        SingletonComponent(BasicComponent).createInstance() line: 85    
        SingletonComponent.getComponentInstance() line: 119     
        SingletonComponent.start() line: 134    
        ComponentStartService.start(StartContext) line: 44
        ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1811     
        ServiceControllerImpl$StartTask.run() line: 1746        
        ThreadPoolExecutor$Worker.runTask(Runnable) line: 886   
        ThreadPoolExecutor$Worker.run() line: 908
        ServiceContainerImpl$ServiceThread(Thread).run() line: 680      
{noformat}

P.S. I was confusing the version numbers of jboss above (corrected I hope). I am using a 7.2.0.Alpha1 snapshot build from about a week ago.

[rhauch]

You know, I vaguely remember that AS7.2 might have broken out the "hibernate-commons-annotations-4.0.1.Final.jar" out of the "org.hibernate" module and into it's own (see AS7-4713). Does your version of AS7.2 have that change? If so , then try changing this line in the "modules/org/hibernate/search-engine/main/module.xml" from:

<module name="org.hibernate"/>

to

<module name="org.hibernate.commons-annotations"/>

(or whatever the new commons module is called).

[bwallis42]

That worked (well the class not found exception is gone)

I now have the following module.xml in modules/org/hibernate/search-engine/4.1

{code}
<module xmlns="urn:jboss:module:1.1" name="org.hibernate.search-engine" slot="4.1">
    <resources>
        <resource-root path="hibernate-search-engine-4.1.1.Final.jar" />
        <resource-root path="hibernate-search-infinispan-4.1.1.Final.jar" />
        <resource-root path="infinispan-lucene-directory-5.1.2.FINAL.jar" />
        <resource-root path="avro-1.5.1.jar" />
        <resource-root path="jackson-mapper-asl-1.9.2.jar" />
        <resource-root path="jackson-core-asl-1.9.2.jar" />
        <resource-root path="paranamer-2.3.jar" />
        <resource-root path="snappy-java-1.0.1-rc3.jar" />
    </resources>
    <dependencies>
        <module name="javax.transaction.api"/>
        <module name="org.hibernate.commons-annotations"/>
        <module name="org.apache.lucene" export="true" slot="3.5"/>
        <module name="org.jboss.logging" />
        <module name="org.jgroups" />
        <module name="org.infinispan" />
        <!-- For naming (used by Hibernate Search Infinispan)... -->
        <module name="javax.api"/>
        <module name="org.jboss.as.naming"/>
    </dependencies>
</module>
{code}

[rhauch]

Glad it worked. Unfortunately, this means we cannot create a kit that works for both AS7.1.1.Final and AS7.2. Hopefully, they'll release 7.2 soon enough that we can just switch to that.

I just logged MODE-1523 so that we make this change when we switch to use AS7.2, and I updated our AS7 installation documentation.

[frolovmx]

I also had that exception with JBoss AS 7.1.3.Final. It is not released, I built it from the source code:

Scm-Revision: f1f5122c0b675454f91e9c458cc1aa9545f2c32c

Scm-Url: https://github.com/jbossas/jboss-as

The solution proposed by Randall Hauch did not work in my environment.

I had to add dependency to module org.hibernate.commons-annotations in two hibernate search modules:

<module xmlns="urn:jboss:module:1.1" name="org.hibernate.search.engine" slot="main">

    <resources>

        <resource-root path="hibernate-search-engine-4.2.0.Final.jar" />

        <resource-root path="hibernate-search-infinispan-4.2.0.Final.jar" />

        <resource-root path="hibernate-search-analyzers-4.2.0.Final.jar" />

        <resource-root path="avro-1.6.3.jar" />

        <resource-root path="jackson-core-asl-1.9.2.jar" />

        <resource-root path="jackson-mapper-asl-1.9.2.jar" />

        <resource-root path="paranamer-2.3.jar" />

        <resource-root path="snappy-java-1.0.4.1.jar" />

    </resources>

    <dependencies>

        <module name="javax.transaction.api" />

        <module name="org.hibernate" />

        <module name="org.hibernate.commons-annotations" />

        <module name="org.apache.lucene" export="true" slot="3.6.2" />

        <module name="org.apache.solr" export="true" optional="true" slot="3.6.2" />

        <module name="org.jboss.logging" />

        <module name="org.jgroups" />

        <module name="org.infinispan" />

        <module name="javax.persistence.api" />

        <!-- For naming (used by Hibernate Search Infinispan) -->

        <module name="javax.api" />

        <module name="org.jboss.as.naming" />

    </dependencies>

</module>

<module xmlns="urn:jboss:module:1.1" name="org.hibernate.search.orm" slot="main">

    <resources>

        <resource-root path="hibernate-search-orm-4.2.0.Final.jar" />

    </resources>

    <dependencies>

        <module name="javax.transaction.api" />

        <module name="org.hibernate" />

        <module name="org.hibernate.commons-annotations" />

        <module name="org.hibernate.search.engine" export="true" services="import" slot="main" />

        <module name="org.jboss.logging" />

        <module name="javax.persistence.api" />

    </dependencies>

</module>

[rhauch]

Unfortunately, the Hibernate modules have recently been undergoing some changes, including in AS7.1.x, mostly to prepare for compatibility with the non-standard Hibernate Search modules. (We're not the only project that will be using them.) This has been problematic for us.

You might want to try EAP 6.1.0.Alpha1. I know "Alpha" sounds scary, but it actually is equivalent to (maybe even a slight improvement over) what would have been AS7.2.0.Final. The upstream JBoss AS has always been "bleeding edge" (it's where the features are first developed) while JBoss EAP is really the stable, ready-to-use, great for production, maintained downstream assembly.

For ModeShape, we really want the more stable server, so starting with ModeShape 3.2 (currently in-work) our kit will be fore EAP. In fact, our "master" branch already is using the EAP 6.1.0.Alpha1 kit, and it has a number of additional fixes/improvements on top of 3.1.3.Final.

[bwallis42]

Hi Randall,

  Just to make sure I understand. Modeshape 3.2 will not have a kit to support jboss AS 7.1.1? It will only have support for the EAP 6.1 release. Does this mean that community releases are no longer going to be supported by modeshape? If I understood Mark Little's recent article correctly, the EAP releases will be available to all developers but not for production installations.

Is this going to cause a problem for users of the community version?

thanks

brian...

[rhauch]

This is all a little bit confusing, so hopefully I can allay your concerns. I really do think this is a good change for the ModeShape community.

The biggest challenge we have with our AS/EAP integration is that ModeShape is very heavily dependent upon Infinispan, but AS/EAP ships a specific version of Infinispan. Ideally, there would be enough AS releases that we can simply pick those versions that include the latest, most stable releases of Infinispan. But for almost all of the 3.0.x and 3.1.x timeline (including all of the alphas, betas, and CRs), there was only one AS7.1.1 release that included only Infinispan 5.1.2.FINAL, and we tied ourselves to this combination. Yes, people embedding ModeShape could forceably upgrade to Infinispan 5.1.8. But in the end, Infinispan 5.1.x had substantial clustering issues that we couldn't work around.

If you recall, for a while during the ModeShape 3.0.0 pre-final releases, we started to include kits for both AS7.1.1.Final and AS7.2. Because AS7.2 had not yet been released (or tagged), we had to build it from source code, which at that point was changing frequently. The result was that our kit would work one week, but would fail to run the next week simply because the AS7.2 code changed. That was why we stopped producing the kit for AS7.2.

In the last few months, as we worked on the 3.1.x releases, we started running into more and more problems in Infinispan that were fixed in the 5.2.x codebase but not in any 5.1.x releases. So while we fixed as much as we could, we were now limited by the fact that the Infinispan community had moved from the 5.1.x line to 5.2.x. Yet we were still stuck with Infinispan 5.1.x because of AS7.1.1.

All that changed when JBoss announced the availability of EAP 6.1.0.Alpha1 (which was for all intents and purposes the same as AS7.2.0.Final would have been) to the community, and that all future EAP alpha releases will also be available to the community. This is a big deal because, while the AS community focuses on rapid evolution of features, JBoss EAP is focused on stability. Red Hat starts with the AS codebase and then spends **a huge** amount of time and effort to test, fix, improve, qualify it and then release it as JBoss EAP. Even the "alpha" releases of EAP are more stable than the community final releases. So it's a huge deal that these more stable EAP alpha releases are available to the community.

It also means that ModeShape can now finally upgrade to Infinispan 5.2.x and still a kit for AS (really EAP) that uses the same Infinispan version. This is the focus of our 3.2 release: fix as many bugs as we can while also upgrading Infinispan, JGroups, Hibernate Search, Lucene, Tika, and other dependencies. Right now, our "master" branch uses Infinispan 5.2.1.Final, but we expect that to change to Infinispan 5.2.5.Final before our 3.2.0.Final release.

Now, Infinispan 5.2.x is not backward compatible with Infinispan 5.1.x, which means that we can no longer maintain our AS7.1.1-based kit. IMO, no longer supporting the combination of AS 7.1.1.Final and Infinispan 5.1.2.Final is acceptable - it was becoming far more of a liability than a benefit for ModeShape. Sure, some very basic configurations might work, but clustering was quite problematic.

In short, ModeShape 3.2 and its dependency upon Infinispan 5.2.x and EAP will be more functional, stable, and clusterable.

Now, let me answer your specific questions:

If I understood Mark Little's recent article correctly, the EAP releases will be available to all developers but not for production installations.

No, that is not quite accurate. Check the FAQs for specifics, but you can run EAP alphas in production. Remember that EAP 6.1.0.Alpha1 is essentially what would have been AS7.2.0.Final. It's just not as stable as EAP 6.1.0.GA will be. Also see this post by the AS community lead about the future plans of AS and how it relates to EAP releases.

IOW, the community can use EAP 6.1.0.Alpha1 (and any other released EAP Alphas) without restriction (other than the LGPL), but if they desire they can also much more easily upgrade to a free developer or paid production subscription.

Our goal is that ModeShape's 3.2.0.Final kit for EAP will run on all flavors of EAP 6.1.0.

Does this mean that [AS] community releases are no longer going to be supported by modeshape?

Assuming that you meant "AS community releases", then yes that is probably the way we're going to go. The upstream AS project is simply too bleeding edge for us, as you certainly can attest. And in the future, AS will likely move even farther towards the "bleeding edge" while the EAP community becomes the place where the community and Red Hat cooperate to make the more stable, production-ready server.

It seems as though the ModeShape community is more interested in running on top of a stable AS-based server, which from this point foward means EAP. So releasing EAP-based kits seems to be in line with the needs of most of our community.

However, I will say that we are open to options. If the ModeShape community wants to maintain an kit for AS upstream in addition to the EAP-based kit, then we're open to proposals for how that's possible. IMO, it might make sense to do this only for AS community releases that precede an EAP release -- once the first corresponding EAP release has been made, the community will move off to their next major version and all fixes will be made on the EAP branch. (See this post by the AS community lead).

Is this going to cause a problem for users of the community version?

Actually, I think this is a much better thing for the ModeShape community - EAP is a more stable platform that always has been more suitable for production.

Does this help?

[bwallis42]

Thanks for the indepth explanation. It helps and causes no problems for me, I just need to understand the story so I can be clear here at work how we stand and what versions of what we will need for delivery. I'm quite happy to use the EAP version for our production releases (always planned on that for future releases).

Infinispan has been a bit of a pain. I am hoping for 5.3.0.Final for EAP 6.1 as I really want to see ISPN-604 fixed (and it is currently planned for 5.3.0)., I really don't want to release a production version with a transactional problem like that in it. I don't suppose I'm going to get that though am I :-(

[ozhou]

Does ISPN-604 only happen in JBOSS AS enviroment and JDBC cache loader?

Currently our project is based on Spring + Atomikos JTA transaction manager + BDB cache loader, it seems that I don't see any exception thrown.

[bwallis42]

As I understand the problem that ISPN-604  will address it is that the transaction used at the user level in updating the repository is not propagated down to the JDBC connection used by the infinispan cache loader. There was a bug as described in the intro for the ticket that caused an exception. This was fixed by suspending the existing transaction before invoking the JDBC interface. Of course this breaks your transactional guarantee in more complex cases.

Take for example if I am using three infinispan caches for the metadata, strings and binary data in the JCR repository. Each of these could be using a different database or schema for their cache loader. The single transaction at the user level when making a change to the JCR is not used for each of the JDBC interactions used to persist the changes, they will create, use and commit their own transactions after the user level one has been suspended. There is no way an error at the database could be correctly rolled back if for example the second JDBC operation to persist the binary data fails after the first JDBC operation (for say the metadata) has already been committed.

The problem isn't a jboss problem, it seems to be related to the design of the interface from infinispan to its cache loaders. As such it may affect the BDB cache loader as well but it is a bit hard to tell from the ticket if this is the case or if it is only related to JDBC based cache loaders.

(Note: there is a bit of guess work here on my part in this description, this is just my understanding of the problem as seen in my own usage and the little bit of info given in the ticket)