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/usergu >> 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
