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

[Jason T. Greene]

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

Btw, switching InvocationContext from a class to an interface is 
compile-time compatible, but it's not binary compatible. Something to 
think about...

-- 
Jason T. Greene
JBoss, a division of Red Hat