Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of jak-commons-dev@m.gmane.org
 designates 80.91.229.3 as permitted sender)
To: dev@commons.apache.org
From: =?UTF-8?B?SsO2cmc=?= Schaible <joerg.schaible@gmx.de>
Subject: Re: [configuration] Design discussion
Date: Fri, 04 Jan 2013 17:47:40 +0100
Lines: 40
Message-ID: <kc713a$ouc$1@ger.gmane.org>
References: <50E3242A.5030301@oliver-heger.de>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
User-Agent: KNode/4.9.3

Hi Oliver,

Oliver Heger wrote:

> Hi,
> 
> recently I have worked on code regarding the creation of Configuration
> objects and reloading support. I have created two Jira tickets [1, 2]
> with a description of the problems I see in the current design.
> 
> The code in SVN (mainly in the new builder package) should be sufficient
> to get a good impression about the direction I would like to go. It is
> far more than a pure proof of concept.
> 
> However, following this road means some significant changes in the
> design and in the way client code uses our classes. Therefore, I would
> really appreciate feedback from other committers also interested in this
> component.
> 
> My main question is: Can we replace the reloading mechanisms available
> in 1.x by an approach based on builders as currently implemented in
> trunk (e.g. classes
> o.a.c.c.builder.ReloadingFileBasedConfigurationBuilder,
> o.a.c.c.reloading.ReloadingController)? If the answer is 'yes', we could
> go forward and significantly simplify most of the file-based
> configuration implementations.
> 
> Thanks
> Oliver
> 
> [1] https://issues.apache.org/jira/browse/CONFIGURATION-519
> [2] https://issues.apache.org/jira/browse/CONFIGURATION-520

simply go-on with these changes. IMHO it looks good and since separation of 
concern leads here to significant code simplification, it's for the best of 
us devs and also for our users in the long term. Especially since the new 
approach brings also improved functionality.

Cheers,
Jörg


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