[jira] Created: (RIVER-144) have PreferredClassProvider wrap ClassNotFoundExceptions to include codebase

["Peter Jones (JIRA)" <ji...@apache.org>]

have PreferredClassProvider wrap ClassNotFoundExceptions to include codebase
----------------------------------------------------------------------------

                 Key: RIVER-144
                 URL: https://issues.apache.org/jira/browse/RIVER-144
             Project: River
          Issue Type: Improvement
          Components: net_jini_loader
    Affects Versions: jtsk_2.0
            Reporter: Peter Jones
            Priority: Minor


Bugtraq ID [5102813|http://bugs.sun.com/bugdatabase/view_bug.do?bug_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.

h4. ( Evaluation note: )

I think that many of the cases that inspired this RFE have already been covered by the implementation of RFE [6254347|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=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.]


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.