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

[Brian Stansberry]

Manik Surtani wrote:
> 
> On 19 Aug 2008, at 16:49, Brian Stansberry wrote:
> 
>> 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.
> 
> ... with the exception of the unit test suite, I suppose.  This would be 
> so in the case of the community version, but then again, that is the 
> status of all JBoss.org projects.  If it is ever used in an EAP, it 
> *would* be tested as a part of the EAP productization process, correct?
> 

I meant untested in the sense that no one is going to test it formally. 
JBC 2.x or 3.x are never going to go in a formal AS 4.x or EAP 4.x 
release. Well, never say never, but the 4.x branches are in bug-fix 
mode.  Perhaps someday JBoss will want to create a release that's more 
than that, but I highly doubt it.

>>> 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.
> 
> Jarjar.  :-)  I really think it would work.  It would make upgrading 
> individual jars hard and may bloat the overall download size a bit, bit 
> it nicely isolates things such that different subsystems may be tied to 
> different versions of dependent libraries.  Actually, upgrading needn't 
> be that hard - e.g., all clustering code could be encapsulated in a 
> single jboss-as-clustering-5.0.jar which includes jarjar'd versions of 
> JBC, JGroups, other deps, as well as AS Clustering classes.  Upgrading 
> could involve a new jboss-as-clustering-5.1.jar which may include a new 
> release of JBC, etc., without affecting other JBC users, whether they be 
> end user apps or other subsystems.
> 

We'll discuss this in Neuchatel.  This kind of thing requires buy-in 
from several projects, e.g. the hibernate integration is part of 
Hibernate; the SFSB integration is part of EJB3. Both of which are meant 
to work outside the AS (Hibernate for sure; EJB3 in as-yet-unrealized 
theory.)

> Now this is slightly trickier in the JGroups case since the AS uses a 
> shared transport, but as long as all components use compatible versions 
> of JGroups then we're ok.
> 
> Perhaps an alternative around OSGi style classloaders could be used 
> instead, but IMO that makes things more troublesome and brittle.
> 
>>
> Cheers,
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 


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