Has anyone used JBC 2.x series with JBossAS 4.2.x series?

[jorgemoralespou_2]

Hi,
I want to upgrade my JBC distribution to a newer one to get some performance improvements and a clearer api. As fas as I know, I can upgrade JGroups to a newer version 2.6 series (required by JBC 2.x), but I need to have legacy JBC 1.4.1 for internal JBossAS caches (EJB cache, etc...).

I need to have cross application access (because I deploy the caches in one ear, and acces it from some other ears) so no classloading isolation is possible.

Any experience with this?

[derrickhackman]

From the documentation:

t is possible to deploy a JBoss Cache 2.0 instance in JBoss AS 4.x (at least in 4.2.0.GA; other AS releases are completely untested). However, the significant API changes between the JBoss Cache 2.x and 1.x releases mean none of the standard AS 4.x clustering services (e.g. http session replication) that rely on JBoss Cache will work with JBoss Cache 2.x. Also, be aware that usage of JBoss Cache 2.x in AS 4.x is not something the JBoss Cache developers are making any significant effort to test, so be sure to test your application well (which of course you're doing anyway.)

http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/beta500/html/ch08s04.html

I have a similar need, out infrastructure is clustered 4.x and I want to upgrade the cache however it appears in a clustered environment I will lose a lot cluster replication capability unless I use the 1.x JBC. Can someone speak to this issue as well as the issue outlined above as we are clearly looking to do the same thing...

thanks
-derrick

[mircea.markus]

We've only investigated integration of JBC2.x in AS 4.x with web replication, not with EJB replication.
see: http://wiki.jboss.org/wiki/JBossCacheAsCompatibility
This is on my todo list, I cannot give any estimate on when this will be finished. It is not officially supported, also.

[jorgemoralespou_2]

This is a pity, since probably there are lots of projects in which isolating the classloaders is not desirable, and seems that introducing JBC2 breaks it all.
If I set up Class Isolation for every app I deploy, I have to bundle common core classes and model, which are stored in cache, and also start a cache for every application. This scenario for me can't work because of lots of factors, being one of them memory consumption and network traffic.

Probably it would have been beter not to keep compatibility at all, and created new package structure, that could have enabled deploying JBC2 in a probably large JBossAS 4.x base.

Now if I want to keep on with JBC, I have to stick with JBC1.4, which is not very performant for me, or wait till JBossAS 5, and migrate all my apps, which is very costy.

I wish this had been taken into account when you decided to make api incompatible JBossCache releases 1 and 2. Hope you think more on this for latter updates, seeing there is a chance that JBC3 don't make it into JBossAS 5.

[derrickhackman]

Pretty much sums up my sentiments on this issue as well. Total drag and a bit of a cowboy nature to the design of JBC2.

[jason.greene]

On this topic, we are planning on a AS5 clustering SPI that will allow for JBC to be easily updated (globally).

[jorgemoralespou_2]

Pitty for those stuck with JBossAS 4 for a while. :-(

[manik]

"derrickhackman" wrote:
Pretty much sums up my sentiments on this issue as well. Total drag and a bit of a cowboy nature to the design of JBC2.

Not really cowboy, but stuff that needed to happen. JBC 1.x had a confusing and occasionally incorrect API.

I do appreciate your concerns regarding backward compatibility though - and I agree that an appropriate translation layer should have been provided in JBC 2.x so it could be run in a "compatible" mode such that it could be dropped into applications written around 1.x.

Jason has started a thread on the jbc-dev mail list to discuss backward compatibility in 3.0, and I'm going to start one to investigate the viability of an adapter package to allow 2.x (and 3.x?) to work in 1.x environments. Stay tuned. :-)

[jorgemoralespou_2]

That would be really great!!!

Thanks.

[manik]

Do join the thread on the dev mail list, any volunteered time/effort in putting this together/testing such adapters will be greatly appreciated, of course. :-)

[derrickhackman]

Manik, the news on backward compatibility is outstanding... I not tossing anyone under the bus regarding my 'cowboy' statement however I have been bitten by this myself and have been called a 'cowboy' and felt I needed to pass along the 'compliment' :-)

I will join the list and see if I can get some time in there to help.
Best
-derrick

[manik]

So the plan is now to update public interfaces in trunk so that 3.x will be API compatible with 2.x (which means in can be used in AS 5).

Now the 1.x compat thing is a somewhat different kettle of fish - and I'm still exploring solutions.

Have you considered using JarJar to move the package names of org.jboss.cache to org.jboss.cache.2 so it doesn't clash with jars shipped in AS 4.x? If this works successfully, we should use this as the recommended pattern as it would then allow AS 4 to use JBC 1.x internally, and 2.x or 3.x code in your apps.