Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
jtsk_2.0
-
None
-
None
-
5102813
Description
Bugtraq ID 5102813
At the point where ClassNotFoundExceptions are caught and logged by applications, information about the codebase is often not available. To aid debugging, it could be useful to have a way to configure PreferredClassProvider to internally catch each ClassNotFoundException and wrap it in (make it the cause of) a new ClassNotFoundException that contains both the class name and the codebase. For those concerned with either performance or security exposures, there should probably be a way to disable this, but perhaps the default should be enabled.
( Evaluation note: )
I think that many of the cases that inspired this RFE have already been covered by the implementation of RFE 6254347 (in 2.1), which made the ClassNotFoundExceptions created in PreferredClassLoader.loadClass and PreferredClassProvider.loadClass/loadProxyClass to wrap around the IOExceptions thrown by PCL.isPreferredResource contain the applicable codebase URL or URL path in their detail messages. Attempting to fetch the preferred list is the first I/O operation performed by a given PCL, so permanent codebase errors are typically detected while doing it.
What remains of this RFE seems to be wrapping the ClassNotFoundExceptions that are caught, logged, and rethrown in PCP.loadClass and PCP.loadProxyClass. In the SecurityException and no-security-manager cases, CNFEs are already wrapped in order to provide more diagnostic detail messages, so wrapping them in the remaining cases doesn't seem problematic. In some cases, like when defaultLoader is null, this wrapping might (at least partially) duplicate information that was already put in the caught CNFE by PCL.loadClass because of 6254347.
[Incidentally, I wonder if the CNFE created in PCP.loadProxyClass to wrap IllegalArgumentException thrown by Proxy.getProxyClass should also include more diagnostic information.]