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, 08 Jun 2013 12:56:37 GMT
Hi again,

I have started created some tasks in JIRA to track this changes [1]. Feel free to add what
is missing.



Am 01.06.2013 um 15:04 schrieb Benedikt Ritter <>:

> Hi Simo,
> Am 01.06.2013 um 14:28 schrieb Simone Tripodi <>:
>> Hi Bene,
>> thanks a lot for following up the discussion, much more than appreciated :)
>>> * The xml module has dependencies to digister. This should be removed if possible
>> What I don't like is not the Digester dependency itself, but rather
>> the fact that:
>> * The XML config module *exposes* Digester APIs - the contract should
>> work strictly to chain configuration APIs, it should have nothing to
>> do with the underlying implementation;
>> * The configuration module relies on the ConfigParser#parse() method
>> behaviour, and returns nothing - that means that 2 different parsers
>> could actually behave in 2 different way, switching from/to different
>> chain textual representations is potentially broken;
>> * Actually only the Config parse operation is available - I honestly
>> think it would be really helpful having a component able also to dump
>> a Chain/Catalog configuration - for that purpose I started exploring
>> Codehaus Modello[1], which is the generator used in Apache Maven; I am
>> not sure if it will give us the solution for that problem, but giving
>> a try shouldn't hurt
> Agreed, sounds exciting!
>>> * 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).
>>> 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?
>> I am honestly against that proposal for the following reasons:
>> * the `api` module just express the Chain contract and has nothing to
>> do how chains are implemented - think about java.util.List and all
>> implementations: of course, the JVM provides default implementations,
>> but nothing prevents users can provide java.util.List implementations
>> that backs data on the file system;
> This depends on what you define as the API. For me, convenience base classes are also
part of the API. Users are free to use them, but can also choose not to. Your example actually
confirms this :-) Think of java.util.AbstractList. It is an abstract convenience base class,
that is shipped as part of the Collections Framework (and not in some impl package). 
>> * not necessarily users have to rely on our chain/commands
>> implementation; having a clear separation between APIs and
>> implementation - and ours is just _one_ implementation, not _the_
>> implementation - allow users compose their system including just what
>> they need;
>> * thinking in therms of OSGi (a topic you like, IIUC) bundles: in a
>> running system, you can upgrade/switch chain bundle implementations
>> without the need of updating the APIs bundles. Yes, it can be done
>> somehow as well with monolith bundles, but having a more fine grained
>> modules, really improve the OSGi experience.
> Yes this is a topic I'm very interested in :-) But I don't see why this change would
affect OSGi-ity of chain.
> I don't think it is absolutely necessary to move the base classes and since you have
objections against this, we should just post pone this discussion until we have the API in
an almost finished shape.
>>> 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.
>> +1 this is something we inherited from previous chain version, feel
>> free to fill an issue and provide the resolution.
> I have created CHAIN-83 [1] for this purpose.
>> Thanks a lot for the followup, have a nice weekend!
>> Alles Gute! :)
>> -Simo
> Thanks, you as well :-)
> Benedikt
> [1]
>> [1]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message