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

[Brian Stansberry]

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).
> 

True enough. If the API BC issue were solved it's likely that 2.x at 
least would work fine, but it would be completely untested.

> 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.
> 

This is one of the main things I want to talk about when we have our AS 
meeting in Neuchatel the week before the Brno meeting. The AS needs a 
general solution to this problem.

> 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.
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com