[ http://issues.apache.org/jira/browse/BEANUTILS-263?page=comments#action_12452137 ] Niall Pemberton commented on BEANUTILS-263: -------------------------------------------
So what happens in Weblogic 9.2 when it "doesn't have access to the class it's trying to load"? Does it throw a ClassNotFoundException or something else? Also have you tested whether your solution works in this situation - i.e. Does the ClassConverter's ClassLoader successfully load the class? At this point my preference would be that we close this as WONT FIX since users can easily create their own custom ClassConverter implementation and register it for their own peculiar environments and I'm not sure whether this is 1) a valid scenario or 2) a workaround for a Welogic bug or 3) deployment error by the user. > Improve ClassConverter robustness > --------------------------------- > > Key: BEANUTILS-263 > URL: http://issues.apache.org/jira/browse/BEANUTILS-263 > Project: Commons BeanUtils > Issue Type: Improvement > Components: ConvertUtils & Converters > Affects Versions: 1.7.0 > Reporter: Alex Albu > Priority: Minor > Fix For: 1.8.0 > > Attachments: ClassConverter.java.patch.txt > > > To load a class by name, ClassConverter attempts to use (in order) the > current thread's context class loader and the class loader that loaded the > class itself. But in my opinion it is a little inconsistent in the way it > does it. Basically, it will use the second class loader as a fallback *only* > if the first one (context class loader) is not set (null). That causes the > converter to fail in environments where the context class loader is set but > does not have access to the class it's trying to load (Weblogic 9.2 is an > example). > I think a more robust behavior would be to try the second class loader *any* > time using the context one fails (be it because it's not set, or it cannot > load the class for some reason). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
