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.

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
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to