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

[Brian Stansberry]

Manik Surtani wrote:
> 
> 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.  :-)
> 

I don't think so, but TBH I haven't thought about it for at least a 
year.  There would be a lot of WARN logging until people changed their 
channel configs to get rid of deprecated stuff.

>> 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 at jboss.org
> 
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev


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