org.jboss.cache.TreeCache and JBoss cache > 1.4.1 "Cayenne"

[roberto]

From release greater then 1.4.1, the TreeCache class doesn't exist anymore (but it was not deprecated! ) :(

I develop an application cache using org.jboss.cache.TreeCache class.

Jboss 4.2.3 is delivered with JBoss Cache 1.4.1, so .. no problem

But JBoss 5 is deliveded with JBoss Cache 3.0.1 and so my application doesn't work anymore!

I don't want to distribute a different version of my application..
There is same way to solve my issue?
Can I use instead of the TreeCache another class?

thanks!

[manik]

There's a lot of documentation on the JBoss Cache wiki on migrating from 1.4.x to 2.x. The 2.x interface hasn't changed much in 3.x.

[roberto]

Thank You Manik
I read wiki page about migration from 1.4 to 2.x
Now I replace jboss cache jar in jboss as 4.2.2 in order to use jbosscache 3.0.1
Using CacheMode=Local it is working.
But an exception occurs starting the war
"10:57:07,984 WARN [TomcatDeployer] Failed to setup clustering, clustering disabled. NoClassDefFoundError: org/jboss/cache/TreeCacheListener"
My web.xml has the "distributalbe" attribute..
but the TreeCacheListener doesn't exists anymore in Jbosscache 3.0.1. I believe that the I cannot change it..

[roberto]

when a war has the "distributable" attribute, the org.jboss.web.tomcat.service.session.JBossCacheManager class is used (defined in the jboss4.2.2//deploy\jboss-web.deployer\META-INF )

This class invoke the JbossCacheService, that invoke CacheListener, that invoke....
I believe that this class (or a called one) was deployed to work only with JBoss Cache 1.4.x and so it try to instantiate the org/jboss/cache/TreeCacheListener but under jbosscache 3.0.1 it doesn't exists...

Someone know how to fix it ?

There is same workaround?
Or is really impossible to use Jboss Cache 3.0.1 under JBoss AS 4.2.2 having a distributable web archive?

Thanks

[brian.stansberry]

Sorry, I don't think deploying a 3.0.1 cache inside an AS 4.x clustered webapp war will work. :( As you've seen, the session replication code needs the 1.4.x classes, so you can't just replace the JBC version in server/all/lib. But if the 3.0.1 classes are in the war, they'll be visible to the session replication code as well, likely leading to incompatible type issue (e.g. which version or org.jboss.cache.Fqn).

[manik]

Brian is correct, you cannot replace JBC 1.4.x with 3.x in JBoss AS 4.x.

I thought you wanted to migrate from 1.4.x to 3.x in one of your custom apps and hence my comment earlier.

If you have a webapp or an ear that directly interfaces with JBC and you want to use the new features in 3.x and still deploy in JBoss AS 4.2, have a look at this link.

[roberto]

Hi and thank you to all
If I understand well, to solve my issue I need to deploy JBC 3.x in me EAR instead to replace it under JBoss AS 4.x using class loader isolation for each app (It seems exactly the scenario descibed in the https://www.jboss.org/community/docs/DOC-10254 as result point 4)

So I try it.
I add to my ear JBC 3.x jar and add the jboss-app.xml :

<jboss-app>
<loader-repository>
org.myapp:loader=SomeClassloader
<loader-repository-config>
java2ParentDelegation=false
</loader-repository-config>
</loader-repository>
</jboss-app>

(according to the http://wiki.jboss.org/wiki/ClassLoadingConfiguration)

If I start JBoss 4.x without standard JBC 1.x jar (the default cfg), it is working, but if I'm using the "all" cfg (the clustered version), I recieve the following exception (using a distributable WAR)

16:40:01,828 ERROR [[/abs]] StandardWrapper.Throwable
java.lang.VerifyError: (class: org/jboss/cache/config/Configuration, method: setCacheLoaderConfig signature: (Lorg/jboss/
cache/config/CacheLoaderConfig;)V) Incompatible argument to function
at org.jboss.cache.config.parsing.XmlConfigurationParser.(XmlConfigurationParser.java:66)
at org.jboss.cache.DefaultCacheFactory.createCache(DefaultCacheFactory.java:82)

Where I can found additional doc in order to help me to fix it ?

[brian.stansberry]

If you want to use sesssion replication, I don't think this is fixable, at least no fix that doesn't involve repackaging the JBC 3 classes as discussed at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200115#4200115.

See my post above where I say

if the 3.0.1 classes are in the war, they'll be visible to the session replication code as well, likely leading to incompatible type issue (e.g. which version or org.jboss.cache.Fqn).

Your java.lang.VerifyError is the kind of thing I was talking about.

[roberto]

Ok thank you.
I decide to keep compatibility with both JBC 1.x and JBC 3.x in order to can use my application on JBoss 4.x and JBoss 5.x
To avoid distributing 2 different version of my class, I decide to use java reflection checking the JBoss cache version installed on the AS.
Thanks to all for the support