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

[Manik Surtani]

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?

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

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