I think that if the resource name starts with a "/", then the class
loader will use it as an absolute path (taking the web app root as
root). If the resource name is relative, the classloader tries all the
entries in the classpath(including jars), as roots, using the resource
name as the path.
musachy
On Mon, Jun 30, 2008 at 10:04 AM, Jeromy Evans
<[EMAIL PROTECTED]> wrote:
> The CodebehindUnknownHandler will search for results using:
> ServletContext.getResource(path); then if not found
> ClassLoaderUtils.getResource(path, getClass())
>
> The path always has a leading slash which is mandatory for the
> ServletContext call.
> However under some(?) conditions ClassLoaderUtils fails to find resources
> located on the classpath within jars when it includes the leading slash.
> eg. if a resource in a webapp is at URI
> "jar:file:/pathtojar/jarfile.jar!/results/success.ftl", then
> ClassLoaderUtils.getResource("/results/success.ftl", getClass()) fails, but
> ClassLoaderUtils.getResource("results/success.ftl", getClass()) succeeds
> (but is NOT used by CodebehindUnknownHandler).
>
> After googling much misinformation I've gotten myself all confused about the
> role of the leading slash. Anyone have an explanation?
> I'm not sure whether I have a local problem, whether Codebehind should test
> for both cases, or whether CodeBehind is broken and has always failed to
> find results in jars.
>
> [Environment: tomcat:5.5.25.0, jvm:1.5.0_13-b05, os: linux
> 2.6.22-14-generic]
>
> Thanks,
> Jeromy Evans
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
