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

[Manik Surtani]

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.

Cheers
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org