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 <simonetrip...@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 <eli...@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.he...@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.he...@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 >>>>>> <simonetrip...@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 >>>>>>> <simonetrip...@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-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
