Am 28.09.2015 um 22:46 schrieb Weygandt, Jon: > I've created an issue. > https://issues.apache.org/jira/browse/CONFIGURATION-611. > > Let me get further into the project, and as I have some more concrete ideas, > I will place them in the comments section.
Thank you, Jon! Looking forward to see your results. Oliver > > Jon > > -----Original Message----- > From: Oliver Heger [mailto:oliver.he...@oliver-heger.de] > Sent: Monday, September 28, 2015 1:35 PM > To: Commons Developers List > Subject: Re: [configuration] Strong coupling between implementation and use > for Beans > > Hi Jon, > > Am 28.09.2015 um 22:18 schrieb Weygandt, Jon: >> Oliver, >> >> I'm considering making an implementation for Hierarchical Configuration. The >> system I have manages multiple applications from a single, large, managed, >> set of configurations. It has some similarities, but it goes beyond simply >> managing "a configuration", it manages configuration and application >> lifecycle, through configuration rollouts, rollbacks, cross colo >> synchronization, and several other things we need. And it uses "beans" quite >> a bit. I was thinking that by bringing in Apache Configuration it would move >> my system a bit towards some existing system, and perhaps one day if my >> system ever goes open source, extend Apache's ability to manage large >> configurations. >> >> So as I think about it more, perhaps some side class, BeanCreationSupport, >> as you suggest would be good. If the user gives BeanCreationSupport a >> configuration, "bean class" and a key, the class could try to fill it in >> using reflection the bean from any type of configuration, not simply >> hierarchal. Reflection could be dumb, simply look for setters, or it could >> try to look at the fields dealing with security managers (which should be >> protected or private). >> >> This method would not even have any dependencies on the specific >> implementation of the config. > > Originally I meant that BeanCreationSupport would be an interface which could > be implemented by concrete Configuration implementations in a specific way. > This is close to your proposal, except that the > getBeanDeclaration() method is not added to an interface derived from > Configuration, but lives in a separate interface. > > Having the bean creation functionality in a helper class would also be an > option. Could it be added to the already existing BeanHelper class? > > Anyway, patches are welcome if you like to work on this. You might want to > create a ticket in our tracking system [1] to follow the issue. This can also > be used for uploading patches. > > Many thanks! > Oliver > > [1]http://commons.apache.org/proper/commons-configuration/issue-tracking.html > >> >> Jon >> >> -----Original Message----- >> From: Oliver Heger [mailto:oliver.he...@oliver-heger.de] >> Sent: Monday, September 28, 2015 12:37 PM >> To: Commons Developers List >> Subject: Re: [configuration] Strong coupling between implementation >> and use for Beans >> >> >> >> Am 27.09.2015 um 18:39 schrieb Weygandt, Jon: >>> It seems that with interfaces like ImmutableHierarchicalConfiguration >>> one should be able to use the configuration independent of the way in >>> which it is implemented. >>> >>> From the >>> example(https://commons.apache.org/proper/commons-configuration/userg >>> u >>> ide/h >>> owto_beans.html#An_Example): >>> >>> Parameters params = new Parameters(); >>> FileBasedConfigurationBuilder<XMLConfiguration> builder = >>> new >>> FileBasedConfigurationBuilder<XMLConfiguration>(XMLConfiguration.class) >>> .configure(params.xml() >>> .setFileName("windowconfig.xml")); >>> XMLConfiguration config = builder.getConfiguration(); BeanDeclaration >>> decl = new XMLBeanDeclaration(config, "gui.windowManager"); >>> WindowManager wm = (WindowManager) >>> BeanHelper.INSTANCE.createBean(decl); >>> >>> It seems that in order to create a bean you must create a >>> BeanDeclaration, which seems to require knowledge of the >>> implementation of the configuration. >>> >>> What if you had a method on ImmutableHierarchicalConfiguration (or >>> ImmutableConfiguration) such as: >>> >>> BeanDeclaration getBeanDeclaration(String key) >>> >>> Then use would not be coupled to an implementation. >>> >>> ImmutableHierarchicalConfiguration config = ... Built any way you >>> want ... >>> BeanDeclaration decl = config.getBeanDeclaration("gui.windowManager"); >>> WindowManager wm = (WindowManager) >>> BeanHelper.INSTANCE.createBean(decl); >> >> This is a valid point. >> >> Historically, bean declarations were only used internally to construct >> combined configurations and their helper objects. This functionality >> seemed to be useful in a more broader context, so the classes were >> exposed to the public. However, there is only a single implementation >> suitable for hierarchical configurations. Therefore, adding a >> getBeanDeclaration() method to ImmutableConfiguration would require that >> corresponding implementations for other types of configurations would be >> created. >> >> Nevertheless, such a method could be added to the >> ImmutableHierarchicalConfiguration interface. Alternatively, a separate >> interface - maybe BeanCreationSupport? - could be added which defines only >> this method. This would be more flexible as it could be implemented by >> various configuration classes independent on their supported Configuration >> interface. >> >> WDYT? >> Oliver >> >>> >>> >>> --------------------------------------------------------------------- >>> 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
