commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject Re: [chain] improving current registry and configuration APIs
Date Sat, 01 Jun 2013 10:21:22 GMT
Am 31.05.2013 um 21:33 schrieb Benedikt Ritter <>:

> Hi again,
> Simo and I had a chat about chain lately. We agreed on the points he has already mentioned
(see below). Some additional issues that we came across:
> * The xml module has dependencies to digister. This should be removed if possible
> * Base classes of the API are currently in o.a.c.c.core.impl package. This is awkward,
because the base classes really belong to the API. I came across this issue while trying to
create a test for o.a.c.c.Chains. I'm not able to use ChainBase in that test because it is
in another module (the core module).

Another point to consider is renaming o.a.c.chain2.generic. When reading a package name like
this I would expect that it has something to do with java generics. But instead it contains
"concrete implementations of generic commands". I'd rename this package to o.a.c.chain2.common
or something like that. 

> As a first step for me to get used to the API, I'd like to to move convenient base classes
like ChainBase and CommandBase to the API package. WDYT?
> Benedikt
> Am 27.05.2013 um 09:31 schrieb Simone Tripodi <>:
>> Hi all Chain-ers,
>> I had yet another small review yesterday[1] at current Configuration
>> APIs and I am not satisfied yet for the following reasons:
>> * org.apache.commons.chain2.CatalogFactory should maybe moved from
>> `core` module to the `api` module;
>> * org.apache.commons.chain2.CatalogFactory is an abstract class, but
>> the static `getInstance()` method relies to a specific concrete
>> implementation;
>> * org.apache.commons.chain2.CatalogFactory mixes the concept of
>> Factory and Registry - more I read that codebase, more I get confused,
>> IMHO it should be split in two different classes with two different
>> roles;
>> * after introducing the configuration facade APIs,
>> org.apache.commons.chain2.CatalogFactory#checkForValidConfigurationModule()
>> lost its purpose - I suggest to drop it and make the CatalogFactory
>> completely un-aware of the existence of the configuration.
>> * the most confusing part is still, IMHO, how the config APIs work:
>> the org.apache.commons.chain2.config.ConfigParser#parse(URL) method
>> parses a textual format of Chain representation and populates
>> org.apache.commons.chain2.CatalogFactory retrieving the static
>> singleton instance and populate it... IMHO, it would be easier if the
>> `parse(URL)` method just returns a CatalogFactory instance.
>> This is just to start, I think much more will come when I'll have
>> another look at current codebase.
>> Now, the question is: is there any committer(s)/contributor(s) that
>> can/wishes to help on the Chain component? Due to my reduced spare
>> time slot, I cannot handle it all alone and it would be good, after
>> more than one year of work, speaking about an RC :)
>> Many thanks in advance, all the best!
>> -Simo
>> [1]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message