commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [chain2] configuration façade APIs
Date Mon, 23 Jul 2012 19:51:46 GMT
Hi Elijah,

not sure we understand each other there, please confirm IIUC - in my
mind I would have extracted "configurations APIs" (mainly interfaces
and few abstract classes maybe) from the configuration module and put
in the core, then renamed the actual configuration module to
`xml-configuration` and let the [digester] dependency - and make the
switch to [configuration] in a second step, taking care on ingesting
same type of input format.

did I understand correctly?
TIA!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Jul 23, 2012 at 9:34 PM, Elijah Zupancic <elijah@apache.org> wrote:
> I've been going through the chain source for about a day looking for a
> way to decouple the digester configuration. Sadly, I don't think that
> I will be able to do it without removing digester. I may just jump
> ahead and remove [digester] completely and then move us to
> [configuration] for creating dynamic chains. That said, my final
> implementation may change because I haven't been able to prototype a
> good solution yet.
>
> Thanks,
> -Elijah
>
> On Mon, Jul 23, 2012 at 11:11 AM, Elijah Zupancic <elijah@apache.org> wrote:
>> Hi Simo,
>>
>> That sounds good to me. However, I'm having trouble separating the
>> existing Catalog implementation from the rest of chain. Digester is
>> tightly coupled across components, so it is a non-trivial refactor to
>> make a configuration facade. I'm working on it, but it will take some
>> time.
>>
>> Thanks,
>> -Elijah
>>
>> On Mon, Jul 23, 2012 at 12:00 AM, Simone Tripodi
>> <simonetripodi@apache.org> wrote:
>>> Good morning all,
>>>
>>> so I continue proposing the already proposed roadmap: let's add the
>>> façade APIs for the [chain] configuration stuff, adapt the existing
>>> XML configuration reader, use the [configuration] in future releases
>>> for new [chain] configurations.
>>> How does it sound?
>>>
>>> best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic <elijah@apache.org> wrote:
>>>> Hi Oliver,
>>>>
>>>> Configuration seems like it might be useful if I end up redoing the
>>>> XML configuration portion. Are there any plans to support YAML?
>>>>
>>>> Thanks,
>>>> -Elijah
>>>>
>>>> On Sun, Jul 22, 2012 at 1:16 PM, Oliver Heger
>>>> <oliver.heger@oliver-heger.de> wrote:
>>>>> Hi Simo,
>>>>>
>>>>> Am 22.07.2012 17:54, schrieb Simone Tripodi:
>>>>>
>>>>>> Good point Oliver,
>>>>>>
>>>>>> I honestly didn't think about [configuration], please apologize!
since
>>>>>> [chain] already had a way to be configured via an XML wrapper around
>>>>>> the Digester, we thought it would have been good having a façade
and
>>>>>> plug other textual format...
>>>>>>
>>>>>> Anyway, we are open to suggestions - what would fit better for you?
Do
>>>>>> you already have some hints to share?
>>>>>>
>>>>>> Many thanks in advance, all the best!
>>>>>> -Simo
>>>>>
>>>>>
>>>>> nothing concrete. I saw that you mentioned an XML configuration module,
and
>>>>> [configuration] contains a XMLConfiguration class. It also supports other
>>>>> configuration file formats, e.g. properties or ini files which can be
>>>>> accessed through the same Configuration interface.
>>>>>
>>>>> I don't know your concrete use cases. If you already have a working
>>>>> implementation based on Digester, there is probably not much benefit
in
>>>>> switching to another API. But if you plan support for other configuration
>>>>> file formats, [configuration] may be worth a look.
>>>>>
>>>>> Oliver
>>>>>
>>>>>
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>>
>>>>>>
>>>>>> On Sun, Jul 22, 2012 at 4:49 PM, Oliver Heger
>>>>>> <oliver.heger@oliver-heger.de> wrote:
>>>>>>>
>>>>>>> Is there any relation or overlap to [configuration]?
>>>>>>>
>>>>>>> Depending on your concrete requirements, this is probably over-sized.
But
>>>>>>> maybe a source of inspiration?
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>> Am 22.07.2012 10:00, schrieb Elijah Zupancic:
>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi
>>>>>>>> <simonetripodi@apache.org> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Just tracked CHAIN-72 and assigned to Elijah
>>>>>>>>>
>>>>>>>>> best,
>>>>>>>>> -Simo
>>>>>>>>>
>>>>>>>>> http://people.apache.org/~simonetripodi/
>>>>>>>>> http://simonetripodi.livejournal.com/
>>>>>>>>> http://twitter.com/simonetripodi
>>>>>>>>> http://www.99soft.org/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Jul 21, 2012 at 11:27 PM, Simone Tripodi
>>>>>>>>> <simonetripodi@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all guys,
>>>>>>>>>>
>>>>>>>>>> Elijah and and I had a chat and we thought that,
since chain2 hasn't
>>>>>>>>>> released yet, we are still in time to define a façade
API for textual
>>>>>>>>>> configurations and rename the current XML configuration
module to
>>>>>>>>>> xml-configuration (and adapt it to new API) - new
formats such as YAML
>>>>>>>>>> and JSON will be included in future releases.
>>>>>>>>>> Any objection?
>>>>>>>>>>
>>>>>>>>>> @Elijah: if you have cycles to dedicate to it, I
think the façade can
>>>>>>>>>> be defined in a o.a.c.chain.config package in the
core module, in that
>>>>>>>>>> way it should be quick enough going to the first
release - WDYT?
>>>>>>>>>>
>>>>>>>>>> TIA!
>>>>>>>>>> -Simo
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>

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


Mime
View raw message