commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weygandt, Jon" <jweyga...@ebay.com>
Subject RE: [configuration] Strong coupling between implementation and use for Beans
Date Mon, 28 Sep 2015 20:46:35 GMT
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.

Jon

-----Original Message-----
From: Oliver Heger [mailto:oliver.heger@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.heger@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

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


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


Mime
View raw message