Re: [jbosscache-dev] Let's make 3.0 backwards compatible

On 19 Aug 2008, at 15:22, Jason T. Greene wrote: > Manik Surtani wrote: >> On 19 Aug 2008, at 06:53, Bela Ban wrote: >>> First of all: I don't think there's a need to make 1.x compatible >>> with 2.x and/or 3.x. The need is there to make 2.x compatible with 3.x. >> I don't know about that. There are still a lot of people who are on >> AS 4.x and who won't switch to AS 5.0 for a while to come. Which >> means they will be stuck on 1.x APIs. See the forum link that >> sparked off this thread > > Thinking about the 4.x problem, API BC is just part of the problem. > Behavioral differences in use by the AS clustering code and hibernate > (i.e. AS4 clustering was not written for 3.x), as well as dependency > differences (1.4.x uses a different jgroups). Are there any API deps that hold back users upgrading JGroups in AS as well? I'm sure I know the answer to this, but it's late, I'm tired and have a presentation to deliver first thing in the morning. :-)

> The root of the problem here is that the AS is exposing it's > internally used APIs, and thereby forcing them on users. If this was > not the case (as it is on other container environments), then users > could happily deploy JBC 3 on AS4.2, and still use EJB/HTTP clustering > > The SPI that Brian is planning helps, but it requires that the user > change the AS clustering implementation, just to change the version of > JBC he/she is using. This could impact other components that share > deps (JBoss Messaging). > > The easiest way to fix this problem, which is done by everyone else, > is to put all of the classes used by AS internally under a new > namespace (package). It could also be done via a special classloader > design, although that would be a massive change, since everyone uses > the context loader for everything. Jarjar, again. I think this really makes sense for included libraries we don't want to expose. BEA et al used to do this when including xerces, etc., and incompatible versions of xerces ran fine together as a result with no classloader gimmickery at all. > We just might not have a simple solution to deploying on 4.2, besides > ripping out the clustering modules. > >> We could but that would mean some sort of package renaming or class >> renaming (e.g., o.j.c.Cache -> o.j.c.Cache3 or o.j.c.3.Cache) and >> o.j.c.Cache remains 2.x compatible. Either way, very ugly for anyone >> who wants to use 3.x APIs directly. >> Specifically, interfaces that have changed include: >> - Cache >> - Fqn >> - EvictionConfig >> - Region/RegionManager >> - EvictionAlgorithm > > IMO, we can just make this stuff BC for the 3.x release. Yep. I need to double-check, but you are probably right. Cheers -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev