Re: [jbosscache-dev] Let's make 3.0 backwards compatible
On 19 Aug 2008, at 16:49, Brian Stansberry wrote:
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
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.