https://issues.apache.org/bugzilla/show_bug.cgi?id=37458
--- Comment #7 from Dave McIntyre <[EMAIL PROTECTED]> 2008-04-16 22:52:03 PST
---
(In reply to comment #6)
> There are a couple of odd things about your stack trace.
>
> 1. For 5.5.23, line 1800 of WebappClassLoader doesn't call Package.isSealed().
> It is around 30 lines later.
>
I agree that this seems odd. I installed a fresh download of 5.5.23 and it
started reporting the error as
java.lang.NullPointerException
at java.lang.Package.isSealed(Package.java:179)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1833)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:873)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1326)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
...
I also tried a fresh install of 5.5.26 and the line numbers changed to
java.lang.NullPointerException
at java.lang.Package.isSealed(Package.java:179)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1839)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:875)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1330)
> 2. I don't understand why the NPE is thrown from within java.lang.Package. If
> pkg was null, I'd expect to see the NPE in WebappClassLoader
>
It's not pkg that is null, it is entry.codeBase which is null. My fault for
posting incorrect line numbers.
> 3. I have checked the source for 1.4, 1.5 and 1.6 and don't see how
> Package.isSealed() could throw a NPE.
>
It is not the call to Package.isSealed() but the call to Package.isSealed(URL
url) which causes the problem: it throws an NPE trying to return
"url.equals(sealBase)".
> I have reviewed the patch you referred to and I do not see a code path by
> which
> this bug could re-appear.
>
In the initial fix for this bug (revision 469360), this section of code was
included in a block which was synchronised on "entry" which contained a smaller
block synchronised on "this". In revision 510801 the synchronisation was
changed to synchronise the outer block on "this", with no synchronisation on
"entry". The problem seems to me to be that although "entry" is a local
variable, the object it references is obtained externally so two different
threads are able to access the same object, and thus one thread is able to set
entry.codeBase to null (at line 1853 in 5.5.23) after the other thread has
entered the block and committed itself to calling pkg.isSealed(entry.codeBase).
> The best place to get help on this is the users list. Before posting please
> try
> a clean 5.5.26 build and also post the OS and JDK you are using. If the
> discussion there concludes there is a bug, please create a new issue to track
> it.
>
Sorry for replying directly here but I thought it was appropriate to reply
directly to your comments. As I say, I see this with a clean 5.5.26 build,
running in CentOS release 4.6 (Final) under Java HotSpot(TM) Client VM (build
1.5.0_14-b03, mixed mode, sharing).
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
