commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Bourg (JIRA)" <>
Subject [jira] [Commented] (CONFIGURATION-551) Make data type conversions extensible
Date Tue, 06 Aug 2013 20:27:48 GMT


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:

    config.get(CustomType.class, key);

he would write:



    new CustomType(config.get(key));

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:
>             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:

View raw message