> I've tracked it down to this (assuming I've found the right svn tag
> correctly):
>
> resourceFile = new File
> (loaderDir, jarEntry2.getName());
>
> resourceFile.getParentFile().mkdirs();
>
>
> What if the file is at the top level (as is the file in ehcache)?
> getParentFile() will return null! In this case, there's no need to create
> any directory, as the file should just be at the root. So this needs just an
> "if"... am I right?
>
>
> A null check won't hurt, but I still don't understand how getParentFile()
> could ever return
> "null" for you.
>
> The WebappClassLoader code snippet you are referring to enumerates the
> static resources
> of the JAR files in WEB-INF/lib, and extracts them to the file system.
>
> For example, if you deploy a web application 123.war which contains a JAR
> file
> WEB-INF/lib/test.jar which in turn contains a top-level resource "abc",
> then a classloader
> request for this resource will cause the entries of WEB-INF/lib/test.jar to
> be exploded to this
> location in your domain:
>
> generated/jsp/123/loader
>
> In other words, the top-level resource "abc" will be written to:
>
> generated/jsp/123/loader/abc
>
> It will always have a parent directory (in this case:
> generated/jsp/123/loader).
>
> Can you elaborate your scenario to help me understand why you are getting
> an NPE?
> Can you try with the trunk build, just to make sure you have the correct
> line number where
> the NPE occurs?
>
I see. So it seems this classloader is being accessed before setWorkDir() is
called to set the loaderDir property...
Scenario: I'm trying to use ehcache as a 2nd level cache provider. I have
configured Hibernate as the JPA provider in persistence.xml, and I'm using
annotations to inject JPA related things. So, while initializing JPA,
Hibernate gets called, which in turns initialize ehcache, which looks for a
resource in its jar.
I'll try soon with a newer build and come back.
Thanks!