commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [beanutils] default converters for File and URL?
Date Fri, 04 Apr 2003 15:29:42 GMT
On Friday, April 4, 2003, at 04:04 PM, Joe Germuska wrote:

> At 3:36 PM +0100 2003/04/04, James Strachan wrote:
>> I wondered if we should add default converters in beanutils that can 
>> turn a String into a File or a URL? It seems like a no brainer and 
>> I'll happily do the work - I just wondered if anyone could imagine a 
>> problem with doing such a thing? I'd find this useful both on Jelly 
>> and on other projects...
> I agree that this is a no-brainer -- but it leads me to speak up about 
> something I was discussing with someone here at work yesterday...
> The static nature of registering converters makes me a little 
> nervous...  are my concerns unfounded?  Or is this just something in 
> how the code evolved that people live with.  I'm worried that I might 
> register a convertor in place of one of the defaults and then break 
> something somewhere else.

Agreed. Though I'm proposing adding default converters for File and URL 
which can be overloaded by user applications if required. So this would 
only break existing code if it was expecting there to be no converter 
for File or URL.

> I'm not sure I understand all of the precedence rules -- is this how 
> it works?  Each ClassLoader has one instance of a Class object for 
> ConvertUtils, and that object is ultimately where the registered 
> converters are stored.  So as long as I don't load ConvertUtils with a 
> shared ClassLoader, there is no risk?  So then, since I'm usually 
> using the BeanUtils package from a web application's WEB-INF/lib, the 
> conversions should only be visible within that web app.

Agreed. Unless commons-beanutils gets into the system ClassLoader :)

It'd be a good idea to use the instance based converter repositories to 
avoid this.

> But what if I'm using some library that has its own conversion needs, 
> for example, in reading in an XML configuration file?   I guess most 
> conversions are pretty universal, volatile, but I can easily imagine 
> conflicting Converters for java.util.Date, for example.
> Should there be some available mechanism like a "ConverterSet" which 
> could be instantiated and then used only in a limited environment?
> Am I thinking about this right?  Or is it really no big deal?

You are and I agree.

ConverterUtils has an instance API called ConverterUtilBean which can 
be instantiated and used privately to avoid clashes.


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

View raw message