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

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(a)jboss.org