commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: [beanutils] default converters for File and URL?
Date Fri, 04 Apr 2003 15:04:40 GMT
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 

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.

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.

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?

Joe Germuska       
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

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

View raw message