[
https://issues.apache.org/jira/browse/CONFIGURATION-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955215#comment-14955215
]
Jon Weygandt commented on CONFIGURATION-611:
--------------------------------------------
The top of the page:
https://commons.apache.org/proper/commons-configuration/userguide/howto_beans.html#Declaring_and_Creating_Beans,
says "Often it is good practice to make heavy use of Java interfaces and
program an application or components against these interfaces rather than
concrete implementation classes."
Except in order to use this fully, either too much needs to be communicated
with the "user of the implementation", e.g. individual BeanDeclarations, or one
must understand the implementation type.
What I realized is that:
* The bean implementation needs to be independent of the Configuration, else
the top of the page is invalid.
* This means the concrete bean class must exist outside of the type of
Configuration sources being used (unless your Configuration supports "code with
configuration", which this system does not)
* Therefore this type of class must be creatable from any
ImmutableConfiguration.
* Additionally I would like to add validation to any Bean being created from a
Configuration.
So I simply adopted a pattern where the constructor for the bean took an
ImmutableConfiguration. This was so dirt simple. And if you don't really have
access to the Bean to create a constructor, simply create a class with a static
builder method, taking the ImmutableConfiguration and returning the Bean.
I also though of using reflection to extract parameters from the
ImmutableConfiguration based on the Bean setters. This could have some worth to
it, but then realized if I want to validate, you cannot validate a partially
constructed Bean, and would need a "commit-like" call, or reflection on the
constructor. I admit I don't understand org.apache.commons.beanutils, maybe
this could do it easily.
Now what to do about the User Guide and code?
* Presumably someone (other than implementation) uses it, is it OK to break
backwards compatibility in this area with configurations2?
* If it is OK, then I'd recommend deleting all the offending classes,
documentation and fix the implementation.
* If it is Not OK, and you, and others, agree that the Bean method is "not
quite fully formed, and independent of implementation" then deprecate the
classes, note in the documentation such, or even refer to the 1.x user guide,
and maybe fix internal implementation.
> Provide methods to create Beans without knowledge of the Configuration's
> implementation
> ---------------------------------------------------------------------------------------
>
> Key: CONFIGURATION-611
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-611
> Project: Commons Configuration
> Issue Type: Improvement
> Reporter: Jon Weygandt
> Priority: Minor
>
> The current method to create a bean uses a pattern that requires the user to
> know of the Configuration's implementation.
> (https://commons.apache.org/proper/commons-configuration/userguide/howto_beans.html#Declaring_and_Creating_Beans)
> It should be possible to decouple this dependency and have some
> implementation independent method.
> One proposal would be to extend the BeanHelper code to implement this in a
> general way.
> Another proposal would be to have an interface that Configurations could
> extend to get the BeanDeclaration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
