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

[bstansberry@jboss.com]

I think we're about 90% on the same page :-)

"manik.surtani at jboss.com" wrote : How would implementation-specific values be set?  Again, using your BuddyLocator example, I presume this would be using BuddyLocatorConfig.getBuddyLocatorProperties()?  We're back to dealing with properties objects; how does this help the MC, except for the case of *known* setters/getters such as getBuddyLocatorClass()?
  | 

The get/setBuddyLocatorProperties() method isn't *really* meant for use by the MC.  It's there to support the old style config, where we parse the existing format.  AFAIK, we still need to support that.

anonymous wrote : 
  | 1)  Use a BuddyLocatorConfig that just contains *known* setters/getters, such as BuddyLocatorClass.

Yep.  But this base class is the one that gets instantiated if we use the old style config. So, the get/setProperties method needs to be there as well to have some way to pass in the config properties if the MC isn't used.

anonymous wrote : 
  | 2)  If people wish to implement their own BuddyLocator, they would also provide their own subclass to BuddyLocatorConfig, adding their own custom setters/getters.
  | 

Yes, that's what I intend.  However, if your BuddyLocator impl is ever going to be used w/ an old-style config file, your BuddyLocator impl needs to also be able to configure itself from a basic BuddyLocatorConfig instance's getProperties() method.

A custom BL impl only used with the MC may not ever concern itself with the Properties; but the standard ones we ship w/ JBC need to be able to configure themselves via Properties.

anonymous wrote : 
  | 3)  The MC would still be able to inject this BLC subclass into the custom BL impl, since the interface methods comply.  The BL impl will be responsible for casting the BLC to the BLC subclass and extracting impl-specific configs.
  | 

If the BL impl needs to support the old style config method, it does this when the BLC is passed in:

a) Check if the BLC is of its custom type.  If yes, cast it and use it directly to configure yourself.
b) If not, it's a base BLC type created from the old style config. Configure yourself from its properties.  (Typically I'd do that by passing the base BLC instance to a c'tor of my custom BLC subclass.  The subclass then knows how to build itself from the Properties.  The BL then uses the custom BLC instance internally.  This approach is an implementation detail though.)

I'm not thinking in terms of the MC injecting a BLC into a BL.  The MC does this:

1) builds a complex, composite Configuration object.  A BLC is just a sub-component of that.  MC creates a BLC, injects that into a BuddyReplicationConfig, which is then injected into the top level Configuration.

2) MC builds the Cache by passing the Configuration into the factory.  Then the internal JBC code builds the cache based on the Configuration; BL gets instantiated and passed its config as part of that.  I think the rules for building a Cache are too complex to try to have the MC do it directly; the factory provides a good encapsulation.

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

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