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