https://issues.apache.org/bugzilla/show_bug.cgi?id=52833
--- Comment #9 from Mark Thomas <ma...@apache.org> 2012-03-19 20:43:53 UTC --- (In reply to comment #8) > What I don't understand is why in the parent classLoader chain having > SystemClassLoader is mandatory! OK. > That's what the current code assume. I know. > Frankly I don't understand why you consider that mandatory. I don't. The original developers of Tomcat did. While I can make some educated guesses why this was done based on the Servlet and J2EE specifications I can't be sure. However, since it is an assumptions that appears in multiple places across the code base I am very reluctant to change it without fully understanding the impacts that might have. > In some env especially osgi it's not!. OK. > The patch just prevent a NPE in case of SystemClassLoader is not in the parent > classLoader chain. No, that patch addresses that particular symptom in one place in the code. As I stated previously, it is the root cause I am interested in fixing rather than one particular symptom. > Why that could not be a valid use case ? As I stated previously, I'm having a hard time coming up with a valid reason for setting the parent class loader to null. Having looked more widely at this issue, it is clear that the implementation of Catalina#getParentClassLoader() is not consistent with other implementations. I'll get that fixed shortly. Depending on what you are doing (which you have yet to be clear about) that may resolve the problem you are seeing. It would be helpful if you could identify which of the following cases is triggering this problem: a) calling Catalina.setParentClassLoader() and passing null b) calling Catalina.setParentClassLoader() and passing a class loader that does not have the system class loader as an ancestor c) Something else. If a) or b) any further details of why this is being done would be helpful. If c) you'll need to provide details. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
