One of the headaches we cause our users, include the AS5 clustering team, is breaking API compatibility on every major release. This is probably the biggest reason why getting JBC3 into an AS5 release is a non-option.

See users complaining: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171065#... I propose that we make 3.0 100% backwards compatible with JBC 2.x. This will improve adoption, and means we stand a chance at becoming a part of an AS5 release. IMO, there is little justification for API changes since our biggest feature / release goal doesn't require it. Also, since we have some API impacting features (partitioning, etc) scheduled for the next major release, it is very possible that we would end up breaking the API twice.

The biggest API change is the Fqn changes, which while the overloaded constructors where broken, we don't have to remove them. We can just mark them as deprecated. Also, while the generics usage doesn't fit the type, it doesn't really hurt anything, so I think we can just live with that past design decision.

The other API change I noticed was XmlConfigurationParser. The old one was renamed to XmlConfigurationParser2x and moved to another package. The new one was named XmlConfigurationParser. Is this considered a public API?. If it is then we should make XmlConfigurationParser choose the appropriate implementation based off of the file format.

On 18 Aug 2008, at 18:39, Jason T. Greene wrote: > One of the headaches we cause our users, include the AS5 clustering > team, is breaking API compatibility on every major release. This is > probably the biggest reason why getting JBC3 into an AS5 release is a > non-option. Not just API - with MVCC, it is also the default configs shipped. Although since 3.0 supports legacy locking schemes, it could always be configured with the legacy locking schemes and a README included explaining how to change these configs. > See users complaining: > http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171065#... > > I propose that we make 3.0 100% backwards compatible with JBC 2.x. > This will improve adoption, and means we stand a chance at becoming a > part of an AS5 release. IMO, there is little justification for API > changes since our biggest feature / release goal doesn't require it. > Also, since we have some API impacting features (partitioning, etc) > scheduled for the next major release, it is very possible that we > would end up breaking the API twice. Agreed about the backward compat.

One of the headaches we cause our users, include the AS5 clustering team, is breaking API compatibility on every major release. This is probably the biggest reason why getting JBC3 into an AS5 release is a non-option. See users complaining: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171065#... I propose that we make 3.0 100% backwards compatible with JBC 2.x. This will improve adoption, and means we stand a chance at becoming a part of an AS5 release. IMO, there is little justification for API changes since our biggest feature / release goal doesn't require it. Also, since we have some API impacting features (partitioning, etc) scheduled for the next major release, it is very possible that we would end up breaking the API twice. The biggest API change is the Fqn changes, which while the overloaded constructors where broken, we don't have to remove them. We can just mark them as deprecated. Also, while the generics usage doesn't fit the type, it doesn't really hurt anything, so I think we can just live with that past design decision. The other API change I noticed was XmlConfigurationParser. The old one was renamed to XmlConfigurationParser2x and moved to another package. The new one was named XmlConfigurationParser. Is this considered a public API?. If it is then we should make XmlConfigurationParser choose the appropriate implementation based off of the file format.

On 18 Aug 2008, at 19:37, Bela Ban wrote: > +100. Do you suggest a bridge/adapter approach ? This could be an alternate approach. We are talking about an adapter for making 2.x and 3.x compatible with 1.x interfaces; it would be much easier to do the same to make 3.x compatible with 2.x. Potentially helps to keep the core 3.x APIs clean so if people want to use 3.x directly they have a chance to use cleaner APIs. The drawback is that everyone uses the adapter and never the cache directly, which beats the purpose of the new APIs altogether. Thoughts?

On 18 Aug 2008, at 19:37, Bela Ban wrote: > +100. Do you suggest a bridge/adapter approach ? This could be an alternate approach. We are talking about an adapter for making 2.x and 3.x compatible with 1.x interfaces; it would be much easier to do the same to make 3.x compatible with 2.x. Potentially helps to keep the core 3.x APIs clean so if people want to use 3.x directly they have a chance to use cleaner APIs. The drawback is that everyone uses the adapter and never the cache directly, which beats the purpose of the new APIs altogether. Thoughts? -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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.

Inline Manik Surtani wrote: > After a good nights' sleep and a fresh mind, I've had a rethink and > have a potential solution. Tell me what you guys think, this will > apply to both 3.x -> 2.x compat, 3.x -> 1.x compat and 3.x -> 2.x > compat. > > 1. For each release, create a "namespace-safe" package. E.g., for > 3.0.0, create jbosscache-core.jar as well as jbosscache-core- > namespace-safe.jar. This would be constructed using jarjar, where > org.jboss.cache.* is translated to org.jboss.cache.3.* (or > org.jboss.cache.2.*). One additional JAR ? -1. jarjar ? -1. That's -2 ...

Sorry, but when I smell complexity, I turn negative... :-)

What about a single adapter, shipped with 3.x, which makes 3.x compatible with 2.x ? I don't hope there will be a 4.x any time soon, which break API compatibility again, so this should be a one- time exercise.

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

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.

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.

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

Brian Stansberry wrote: > Manik Surtani wrote: >>> 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.) > In the meantime, I think what we can do to solve the 4.2 issue, is to provide the community with an ant task that would use jarjar to create a fully isolated jar for jboss cache and all of its dependencies.

On 20 Aug 2008, at 04:28, Bela Ban wrote: > I added an item to our agenda for Brno, so we can discuss it there (on > FRI, but this will get shifted around anyway) Hmm, re: 3.x, I think we need to move a bit quicker than that. I'm holding back 3.0.Beta1 until we decide on this approach, since it will affect whether: 1. I revert to JBC 2.x interfaces 2. move 3.x interfaces to a new package 3. stick with new 3.x interfaces and rely on an adapter package. Thoughts? Anyone want to take a vote on this? :-)

Manik > > > Jason T. Greene wrote: >> Brian Stansberry wrote: >>> Manik Surtani wrote: >>>>> 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.) >>> >> >> In the meantime, I think what we can do to solve the 4.2 issue, is to >> provide the community with an ant task that would use jarjar to >> create a fully isolated jar for jboss cache and all of its dependencies. >> > > -- > Bela Ban > Lead JGroups / Clustering Team > JBoss - a division of Red Hat > > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

> > #1, I don't know how much that screws you up. #1 seems like the cleanest/easiest thing as far as the AS and other API consumers are concerned, even if it does pollute JBC API. I plan to spend a few cycles today revisiting these and seeing what can be done to maintain compat. For the most part (Cache, Fqn, CacheFactory) this should be ok, just would mean having a lot of deprecated methods around, but for the Eviction and Region interfaces it could be tricky. Could mean some sort of internal adapter.

Manik Surtani wrote: > > On 21 Aug 2008, at 09:11, Manik Surtani wrote: > >>> >>> #1, I don't know how much that screws you up. >> >> #1 seems like the cleanest/easiest thing as far as the AS and other >> API consumers are concerned, even if it does pollute JBC API. I plan >> to spend a few cycles today revisiting these and seeing what can be >> done to maintain compat. For the most part (Cache, Fqn, >> CacheFactory) this should be ok, just would mean having a lot of >> deprecated methods around, but for the Eviction and Region interfaces >> it could be tricky. Could mean some sort of internal adapter. > > Ok, I think this is doable. Unnecessary deprecated crud on most > interfaces, but this is ok. The only *really* messy one is the > eviction stuff. To do this, I have: > > 1. Reverted interfaces so that EvictionPolicy, EvictionPolicyConfig > and EvictionAlgorithm are as they were in 2.x. > 2. My new EvictionAlgorithm interface and it's > EvictionAlgorithmInterface have been renamed to EvictionSelector and > EvictionSelectorConfig - as I should have done from the beginning to > prevent confusion > 3. Internal eviction logic all use the EvictionSelector and > EvictionSelectorConfig interfaces. > 4. I have created an EvictionAlgorithmSelectorBridge which implements > EvictionSelector, which will be used when a legacy EvictionPolicy is > detected. > 5. Existing EvictionAlgorithm implementations have now been renamed > XXXSelector and implement EvictionSelector > 6. The original XXXAlgorithm classes extend the XXXSelector, > implement EvictionAlgorithm and are marked as deprecated, and are just > here as an extension point. > 7. New features, such as EvictionActionPolicies, are not supported by > this bridge (naturally!) > > Not checked any of this in as yet, still testing away. :-) I ought > to be ready to check this in tomorrow, test with AS 5 trunk, etc. > I saw your changes, and reverted my recent POJO Cache changes to restory the usage of the 2.x API. I had to make some other changes including: - Resurrecting JmxUtil (this is needed by PojoCacheJmxWrapper, to know where to register CacheJmxWrapper) - Move InvocationContext from org.jboss.cache.invocation to org.jboss.cache (otherwise the 2.x import statements will break) - Restored generics on Fqn, but with some nice improvements that make them useful: i.e. you can now do stuff like: Fqn<String> fqn = Fqn.fromString("/a/b/c"); Fqn<Object> fq2 = Fqn.fromRelativeElements(fqn, new Object()); Also, there are still issues with JMX. The wrappers no longer support the old format, and some properties have been dropped. Also I need to somehow mirror the new JMX API for POJO Cache, although is it ready yet?

On 26 Aug 2008, at 01:02, Jason T. Greene wrote: > Btw, switching InvocationContext from a class to an interface is > compile-time compatible, but it's not binary compatible. Something to > think about... Hmm yes, this could be a tough one. Most of the other places where interfaces were introduced were internal stuff, so it wouldn't make a difference - InvocationContext is exposed though. The interface is needed though to be able to provide different behaviour for different locking schemes. Perhaps making it an abstract class instead will have to be the way to go. Ugly, but ...

On 26 Aug 2008, at 00:50, Jason T. Greene wrote: > Manik Surtani wrote: >> On 21 Aug 2008, at 09:11, Manik Surtani wrote: >>>> >>>> #1, I don't know how much that screws you up. >>> >>> #1 seems like the cleanest/easiest thing as far as the AS and other >>> API consumers are concerned, even if it does pollute JBC API. I >>> plan to spend a few cycles today revisiting these and seeing what >>> can be done to maintain compat. For the most part (Cache, Fqn, >>> CacheFactory) this should be ok, just would mean having a lot of >>> deprecated methods around, but for the Eviction and Region >>> interfaces it could be tricky. Could mean some sort of internal >>> adapter. >> Ok, I think this is doable. Unnecessary deprecated crud on most >> interfaces, but this is ok. The only *really* messy one is the >> eviction stuff. To do this, I have: >> 1. Reverted interfaces so that EvictionPolicy, EvictionPolicyConfig >> and EvictionAlgorithm are as they were in 2.x. >> 2. My new EvictionAlgorithm interface and it's >> EvictionAlgorithmInterface have been renamed to EvictionSelector and >> EvictionSelectorConfig - as I should have done from the beginning to >> prevent confusion >> 3. Internal eviction logic all use the EvictionSelector and >> EvictionSelectorConfig interfaces. >> 4. I have created an EvictionAlgorithmSelectorBridge which >> implements EvictionSelector, which will be used when a legacy >> EvictionPolicy is detected. >> 5. Existing EvictionAlgorithm implementations have now been renamed >> XXXSelector and implement EvictionSelector >> 6. The original XXXAlgorithm classes extend the XXXSelector, >> implement EvictionAlgorithm and are marked as deprecated, and are >> just here as an extension point. >> 7. New features, such as EvictionActionPolicies, are not supported >> by this bridge (naturally!) >> Not checked any of this in as yet, still testing away. :-) I ought >> to be ready to check this in tomorrow, test with AS 5 trunk, etc. > > I saw your changes, and reverted my recent POJO Cache changes to > restory the usage of the 2.x API. I had to make some other changes > including: > > - Resurrecting JmxUtil (this is needed by PojoCacheJmxWrapper, to know > where to register CacheJmxWrapper) Have you had a look at the new JMX stuff that Mircea has written? Could you not use those instead of JmxUtil?

> - Move InvocationContext from org.jboss.cache.invocation to > org.jboss.cache (otherwise the 2.x import statements will break) Good catch. > - Restored generics on Fqn, but with some nice improvements that make > them useful: > > i.e. you can now do stuff like: > Fqn<String> fqn = Fqn.fromString("/a/b/c"); > Fqn<Object> fq2 = Fqn.fromRelativeElements(fqn, new Object()); I had already restored these in trunk (by adding the <E> template on the Fqn class), but hadn't genericised return types on the methods. Thx for fixing the factory methods. > Also, there are still issues with JMX. The wrappers no longer support > the old format, and some properties have been dropped. Also I need to > somehow mirror the new JMX API for POJO Cache, although is it ready yet? Yes, this is - Mircea? Feel like pitching in?

Also, what do you mean by the "old format"? The JmxCacheWrapper should not have changed.

On 19 Aug 2008, at 20:33, Jason T. Greene wrote: > Brian Stansberry wrote: >> Manik Surtani wrote: >>>> 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.) > > In the meantime, I think what we can do to solve the 4.2 issue, is to > provide the community with an ant task that would use jarjar to create > a fully isolated jar for jboss cache and all of its dependencies. I think the best approach would be a jbosscache-core-compat module (on the same level as jbosscache-core) which consists of a Maven POM which depends on jbosscache-core, which just handles the package relocation and spits out jbosscache-core-compat. Then another pair of modules - jbosscache-core-compat-1.x and jbosscache-core-compat-2.x - which depend on jbosscache-core-compat and provide interface bridges to 1.x or 2.x interfaces would do the trick.

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

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.

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.

On 18 Aug 2008, at 19:37, Bela Ban wrote: > +100. Do you suggest a bridge/adapter approach ? This could be an alternate approach. We are talking about an adapter for making 2.x and 3.x compatible with 1.x interfaces; it would be much easier to do the same to make 3.x compatible with 2.x. Potentially helps to keep the core 3.x APIs clean so if people want to use 3.x directly they have a chance to use cleaner APIs. The drawback is that everyone uses the adapter and never the cache directly, which beats the purpose of the new APIs altogether. Thoughts? -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org