ctubbsii commented on issue #3871: URL: https://github.com/apache/accumulo/issues/3871#issuecomment-1772351687
It seems like this isn't necessary, as this can be handled in the ContextClassLoaderFactory implementation itself with a well-written implementation. Our uncaught exception handler is to protect Accumulo itself from unknowable JVM states, often caused by bad user pluggable code that Accumulo cannot safely reason about. Even something that seems as simple as NoClassDefFoundError can be accompanied by serious state changes in the JVM. For example, a NoClassDefFoundError can occur because of an exception in a static initializer block while trying to load a class. One problem is that that static initializer can change some JVM-wide state before it fails, leading to an unknowable state. So, even though the class couldn't load, it doesn't mean the JVM is in a knowable good state. These errors are fatal because they can leave the JVM in a bad, often unknowably bad, state. The NoClassDefFoundError can also be caused by a previous failure to load a class that was cached by the system classloader. The first time it tried to load, it might throw an ExceptionInInitializerError or other LinkageError. Subsequent attempts might simply report NoClassDefFoundError because the classloader is aware that there's no valid class definition available, and this would not be recoverable. These kinds of errors are different from say, ClassNotFoundException, which is a recoverable error that can happen when trying to dynamically load a class with something like Class.forName or similar. This can be recoverable if the reason it failed to load was because an item was missing from the classpath and has been subsequently placed there, or if there was a config typo and that typo was subsequently fixed. In either case, though, most of these situations can be addressed by having a good classloader implementation that behaves the way the user wants it to, or by having good configuration management to ensure their system is deployed properly. I think the least best option is allowing users to muck about with changing how Accumulo protects itself and the user data it is responsible for, as the result of user errors during deployment, and that's one role I think the server-side uncaught exception handler is often doing. I think there are better approaches already available to users that have not been exhausted, in particular the use of a robust pluggable ContextClassLoaderFactory implementation that satisfies the user's behavioral requirements, that would be far less risky. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
