DocumentBuilderFactory test ClassCastException about classloader-leak-prevention HOT 4 CLOSED

I changed the implementation to catch all Exceptions ocurring during javax.xml.parsers.DocumentBuilderFactory.newInstance().newDocumentBuilder(). The change is on GitHub but no JAR is available yet.

The ClassCastException will be logged as an error, however. Can you work with that, or do you still need to be able to override this?

from classloader-leak-prevention.

Hmmm, I don't really want a stack trace every time I deploy but I am already overriding the error(Throwable t) method and I could selectively suppress the stack trace in some cases. Since no message is passed in to the error method I don't really have much infomation to log (besides the stack trace) to tell me where the error occurred. If a message was passed in about what failed I could log something like "JAXP leak avoidance measure failed due to: " + e.getClass().getName() + " : " + e.getMessage().

I think passing a brief message to the error method and/or moving those contextInitialized blocks of code to protected methods would both be worthwhile. Those methods would also provide a good place for comments about the leak, without making the contextInitialized method really long.

I can work with this for now and if I get time I might provide a patch, at least for the error methods.

Regarding logging stack traces, I see you are avoiding logging a stack trace that occurs on JBoss. If there is a stack trace that occurs for a particular application, it is probably specific to a particular app server or JVM and chances are they will eventually want to suppress it, but still have access to the stack trace initially. Maybe a configuration option could be used to determine whether the listener logs stack traces for errors or just messages.

Thanks for creating this listener. I am still adding it to applications and eventually I will have to do the hard work to determine if the classloader leaks for all our applications are gone. That seems like it is going to be a painful process since you can't just deploy and undeploy an app, force a permgen GC and see if it worked. Between deploy and undeploy you have to excercise all the various functionality, frameworks, and libraries in the application that might cause a leak. Your listener does seem to get most types of leaks so another strategy might be to put the listener in all applications and then just deploy all apps to our development environment every night from Jenkins and if the servers stay up for a week then the leaks must be taken care of (assuming there is enough testing activity in dev to excercise the apps). If the JVM crashes then the heap dump can be analyzed per your instructions.

from classloader-leak-prevention.

The logger category, excetpion name, and exception message make the error I am logging descriptive enough and I have only seen an error on one application (which probably should be fixed in some way) so I am closing this issue.

from classloader-leak-prevention.

Glad to hear it worked out, since I didn't find the time to look at it further.

from classloader-leak-prevention.