commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] Strong coupling between implementation and use for Beans
Date Mon, 28 Sep 2015 20:34:31 GMT
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

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!


> Jon
> -----Original Message-----
> From: Oliver Heger [] 
> 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(
>> 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.
> Oliver
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message