commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [convert]Another use case
Date Fri, 05 Mar 2004 23:48:18 GMT
From: "Oliver Heger" <>
> This service can be quite generic
> and not configuration specific. Because the [convert] project deals with
> data type conversion it seems to be a good starting place.
Yes, [convert] is intended for general data conversion problems.

> - An interface defining a conversion source, which could look as follows:
> public interface ConversionSource {
>   Object getProperty(Object key, Object defaultValue);
> }
> - A class that can be instantiated with such a conversion source as
> argument. This class would define a couple of getter methods for
> properties with different data types. Internally such a getter would
> fetch the properties from the conversion source object, perform the
> necessary conversion and return the result (or throw an exception).

I think I follow, but I'm not certain if its suitable for [convert].
[convert] is intended to provide the mechanism of defining and plugging
together the converters themselves. How they are used in an application is
application specific. At present I want to keep the [convert] project small
and simple.

Having said that, it _may_ be that this interface naturally fits into
[convert] anyway. I really need to just get in there and finish it up.

> What do you think of this approach? If I provided some patches for this
> feature, would somebody be willing to apply them?
At present, I reckon [convert] is not advanced enough for this discussion.
But if you want to help progress the underlying project then that would be

> BTW, what is the actual status of the [convert] project (I had trouble
> when building the latest CVS version; two unit tests fail)?
Status: waiting for time to attend to it.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message