commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Weygandt (JIRA)" <>
Subject [jira] [Commented] (CONFIGURATION-611) Provide methods to create Beans without knowledge of the Configuration's implementation
Date Tue, 13 Oct 2015 16:20:05 GMT


Jon Weygandt commented on CONFIGURATION-611:

The top of the page:,
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

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:
>             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. (
> It should be possible to decouple this dependency and have some implementation independent
> 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

View raw message