commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
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 <beneritter@gmail.com>:

> 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 <simonetripodi@apache.org>:
> 
>> 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] http://svn.apache.org/viewvc?view=revision&revision=1486478
>> 
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message