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. 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
