[jboss-dev-forums] [Design of JBossCache] - Re: POJOization of config elements

[bstansberry@jboss.com]

anonymous wrote : 
  | Why doesn't the standard BL impl we ship with (there is only one) also come with a BLC subclass, could be a good example since Properties are ugly and we don't really want to promote that mechanism anyway?
  | 

I've written one.  Also, the same pattern applies to CacheLoaders (substitute CacheLoaderConfig for BuddyReplicationConfig and IndividualCacheLoaderConfig for BuddyLocatorConfig.)  I've got specific IndividualCacheLoaderConfig subclasses created for all the standard CacheLoader impls as well.

anonymous wrote : 
  | Why do we need to support Properties anyway, for 2.0.0 we don't need to be backward-compat ...
  | 

We still want to support creation of a config using the old 1.x format and XmlConfigurationParser, don't we?  Otherwise we require use of the MC and a -beans.xml file, even outside the AS.  The XmlConfigurationParser approach can't handle arbitrary sets of XML elements (at least not without a lot of work), hence the use of Properties as a workaround.

Even if we decide to require use of the MC in 2.0.0.GA, leaving in Properties support for now makes it easier to transition.  We can strip it out later (e.g. after alpha).


FYI, I've been proceeding along the lines discussed on this thread trying to see if there are problems.  Here's where it stands:

1) Custom config classes created for all NextMemberBuddyLocator, and all the CacheLoader impls, and impls designed to use them.
2) AFAICT, there are no testsuite regressions using this code (i.e. all the existing tests that use properties for configuration pass.  The various config classes all know how to convert from the Properties format to POJO properties, so the existing testsuite is excercising this stuff fairly well.

TODO:

1) Continue discussion.

2) If it sounds good, continue along same lines with eviction policies.  This might be easier, as it looks like the eviction policy config is already somewhat done along these lines; e.g. a lot of specialized config classes exist.

2) Set up -beans.xml files for use in the AS to test building the standard cache configs used in the AS.  That's provides a basic test of the MC approach.

3) Round out the JBC test suite with more formal tests of the MC approach.  I'd say that can be done post-alpha.

How's that sound?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979455#3979455

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979455