Bug fix for LocalUtil

[moonfruit]

Previous LocalUtil.java makes below useless:
clazz = Thread.currentThread().getContextClassLoader().loadClass(remappedClassName);
Because of the next:
clazz = LocalUtil.class.getClassLoader().loadClass(remappedClassName);

[dmarginian]

What bug is being fixed with this change? It appears to be a stylistic change that doesn't impact the results.

[moonfruit]

You can see this:

dwr/core/api/main/java/org/directwebremoting/util/LocalUtil.java

Lines 1179 to 1197 in c1d9375

	String remappedClassName = remappedDwrClassName(className);
	Class<?> clazz = null;
	try {
	clazz = Thread.currentThread().getContextClassLoader().loadClass(remappedClassName);
	} catch(ClassNotFoundException ex) {
	// fall through
	} catch(IllegalArgumentException ex) {
	// Conform to JDK classloader behaviour where illegal classnames are handled as ClassNotFound
	// fall through
	}
	try {
	clazz = LocalUtil.class.getClassLoader().loadClass(remappedClassName);
	} catch(IllegalArgumentException ex) {
	// Conform to JDK classloader behaviour where illegal classnames are handled as ClassNotFound
	throw new ClassNotFoundException(ex.getMessage(), ex);
	}
	return clazz;

the code run this:

clazz = LocalUtil.class.getClassLoader().loadClass(remappedClassName);

immediately after this:

clazz = Thread.currentThread().getContextClassLoader().loadClass(remappedClassName);

So even clazz = Thread.currentThread().getContextClassLoader().loadClass(remappedClassName) is successful returned, the program will also run clazz = LocalUtil.class.getClassLoader().loadClass(remappedClassName), this makes clazz = Thread.currentThread().getContextClassLoader().loadClass(remappedClassName) useless.
Or we can just run clazz = LocalUtil.class.getClassLoader().loadClass(remappedClassName) if this is you wanted, but I think not.

[dmarginian]

Yes, thanks. I wonder if the first attempt is even needed. I would have to look into more but this change looks fine.