commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [chain] improving current registry and configuration APIs
Date Sat, 01 Jun 2013 12:28:19 GMT
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

> * 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;

 * 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.

> 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.

Thanks a lot for the followup, have a nice weekend!
Alles Gute! :)


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

View raw message