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

[Jason T. Greene]

Manik Surtani wrote:
> 
> 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?

Yeah, it's not compatible with the jmx wrapper stuff.

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

Sure, if Mircea could do a quick overview of what the goals and usage of 
this API are, I could look at extending it to POJO Cache.


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

It was updated to take the new config file format, as were all tests 
that use it:

  private BuddyElementParser buddyElementParser = new BuddyElementParser();
    private LoadersElementParser loadersElementParser = new 
LoadersElementParser();
    private EvictionElementParser evictionElementParser = new 
EvictionElementParser();


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