Re: [jbosscache-dev] Let's make 3.0 backwards compatible
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