[
https://issues.apache.org/jira/browse/CONFIGURATION-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731228#comment-13731228
]
Emmanuel Bourg commented on CONFIGURATION-551:
----------------------------------------------
The basic types found in a configuration file are pretty much all covered
already (We'll have to add the new date types of Java 8). If a user wants to
convert a string to a custom type I guess he already has a parse method that
can be used. So instead of writing:
{code}
config.get(CustomType.class, key);
{code}
he would write:
{code}
CustomType.parse(config.get(key));
{code}
or
{code}
new CustomType(config.get(key));
{code}
Which is still simple and saves the plumbing of the conversion framework. So in
order of preference I would rather keep the conversion mechanism internal or
switch to one external framework, but supporting several conversion frameworks
seems quite complex and doesn't bring much value for the end user.
Just a random thought, we could probably support custom types by analyzing the
constructors and the static methods of the class. If the class contains a
public constructor with a String parameter or a static method named parseXXX()
it could be used automatically.
> Make data type conversions extensible
> -------------------------------------
>
> Key: CONFIGURATION-551
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-551
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Type conversion
> Affects Versions: 1.9
> Reporter: Oliver Heger
> Fix For: 2.0
>
>
> So far, a fix set of data type conversions is supported. Some are available
> directly in the {{Configuration}} interface (especially for primitive and
> standard Java types), others are provided by {{DataConfiguration}}.
> Currently, it is not easy possible for client applications to customize type
> conversions or add new converters.
> I am not sure whether we should go so far to implement yet another framework
> with type converters; at least not directly for version 2.0. However, there
> should be at least possibilities to hook into the conversion mechanism.
> Ideally, I would like to have a simple facade handling the different kinds of
> conversions. By providing alternative implementations, client applications
> should be able to adapt type conversions or even plug in a different
> conversion framework, e.g. Commons Beanutils.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
