You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simone Tripodi <si...@apache.org> on 2013/05/27 09:31:14 UTC
[chain] improving current registry and configuration APIs
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
Re: [chain] improving current registry and configuration APIs
Posted by Simone Tripodi <si...@apache.org>.
Hi Bene!
thanks a lot in advance! new fresh energies are required at all
levels, from giving feedbacks 'till leg-work! :)
welcome aboard!
Alles Gute!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, May 28, 2013 at 8:43 AM, Benedikt Ritter <br...@apache.org> wrote:
> Hi Simo,
>
>
> 2013/5/27 Simone Tripodi <si...@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 :)
>>
>
> I didn't have the time to take a look at the code base, but I'm interested
> in getting involved. I will probably have a few cycles the next days. After
> I have digged into the code I'll comment on the topics you mentioned.
>
> This is going to be fun! :)
>
> Benedikt
>
>
>>
>> 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
>>
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain] improving current registry and configuration APIs
Posted by Benedikt Ritter <br...@apache.org>.
Hi Simo,
2013/5/27 Simone Tripodi <si...@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 :)
>
I didn't have the time to take a look at the code base, but I'm interested
in getting involved. I will probably have a few cycles the next days. After
I have digged into the code I'll comment on the topics you mentioned.
This is going to be fun! :)
Benedikt
>
> 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
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [chain] improving current registry and configuration APIs
Posted by Benedikt Ritter <be...@gmail.com>.
Am 31.05.2013 um 21:33 schrieb Benedikt Ritter <be...@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 <si...@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
Re: [chain] improving current registry and configuration APIs
Posted by Benedikt Ritter <be...@gmail.com>.
Hi again,
I have started created some tasks in JIRA to track this changes [1]. Feel free to add what is missing.
Benedikt
[1] https://issues.apache.org/jira/browse/CHAIN-84
Am 01.06.2013 um 15:04 schrieb Benedikt Ritter <be...@gmail.com>:
> Hi Simo,
>
> Am 01.06.2013 um 14:28 schrieb Simone Tripodi <si...@apache.org>:
>
>> 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] https://issues.apache.org/jira/browse/CHAIN-83
>
>>
>> [1] http://modello.codehaus.org/index.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>> ---------------------------------------------------------------------
>> 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
Re: [chain] improving current registry and configuration APIs
Posted by Benedikt Ritter <be...@gmail.com>.
Hi Simo,
Am 01.06.2013 um 14:28 schrieb Simone Tripodi <si...@apache.org>:
> 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] https://issues.apache.org/jira/browse/CHAIN-83
>
> [1] http://modello.codehaus.org/index.html
>
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
> ---------------------------------------------------------------------
> 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
Re: [chain] improving current registry and configuration APIs
Posted by Simone Tripodi <si...@apache.org>.
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! :)
-Simo
[1] http://modello.codehaus.org/index.html
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [chain] improving current registry and configuration APIs
Posted by Benedikt Ritter <be...@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).
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 <si...@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