Re: [Springframework-developer] Classloading issue to resolve before M3 release!

[<jue...@we...>]

Colin,
=20
I've been messing around with that myself for a while, and have also =
modified that ClassLoaderUtils method. I didn't realize that =
ClassLoader.getResourceAsStream does not accept leading slashes! - I =
thought they would work as absolute paths with both =
Class.getResourceAsStream and ClassLoader.getResourceAsStream.
=20
As for the context class loader, you're right that we should be able to =
rely on it in any case anyway. ClassLoaderUtils.getResourceAsStream was =
intended as framework-internal class anyway: Nowhere within the =
framework does loading relative to a framework class make any sense.
=20
It may make sense though to accept leading slashes in paths, as many =
callers don't want to worry about whether the path gets interpreted by =
Class or ClassLoader. For example, Hibernate's Configuration object =
needs the slash, as it loads via =
Environment.class.getResourceAsStream...
=20
To stick to the principle of least surprise, I strongly vote for =
treating "/a/b/myresource" the same as "a/b/myresource". This way, =
callers don't need to worry about the actual loading strategy. They can =
stick to the latter pattern, which is correct for ClassLoader usage, but =
also the former, for example if used to it from Hibernate.
=20
I've just committed that fix. Does that work for you too?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: So 23.11.2003 21:37
An: spr...@li...
Betreff: [Springframework-developer] Classloading issue to resolve =
before M3 release!



I just figured out that we have an issue with the existing code in
ClassloaderUtils.getResourceAsStream, which is used in a number of =
places.

Whoever wrote the original method:

    public static InputStream getResourceAsStream(Class clazz, String
name) {
        ClassLoader ccl =3D =
Thread.currentThread().getContextClassLoader();
        InputStream in =3D null;
        if (ccl !=3D null) {
            in =3D ccl.getResourceAsStream(name);
        }
        if (in =3D=3D null) {
            in =3D clazz.getResourceAsStream(name);
        }
        return in;
    }

did not realize that ClassLoader.getResourceAsStream and
Class.getResourceAsStream do _not_ behave the same way w/regards to the
path this is supplied to them.

Class.getResource, expects to be given a path which is either relative
or absolute to that class, as indicated by a leading /. If there is a
leading slash, it strips off that slash, then passes on the request to
its classloader (ie it calls ClassLoader.getResource). If there is no
slash, it prepends the class package (without a leading slash) to the
specified path, then calls getResource on its classloader.
ClassLoader.getResource, on the other hand, expects that it is given
only absolute paths, _without_ a leading slash. And it will fail if
there is a leading slash.

As such, if the code above is called with a path that is correct for the
call to the context classloader (ie no leading slash), it will be
incorrect for the call to class.getResource (as it will be considered
relative). If it is called with code that is fully qualified/absolute
and correct for the class.getResurce (ie it has a leading slash), it
will always fail for the context classloader getResource call.

Not good... Now this code is used in a number of places, usually with
'/' prepended on the actual path. That is, the code assumes the resource
lookup behaves in a similar fashion to Class.getResource, not
ClassLoader.getResource.  In that respect, the solution of 'least
surpirse' is to treat the context classloader case the same. Even though
it doesn't actually use the class package, if the path doesn't start
with '/', it should be assumed to be relative and added to the specified
resource path. Then this should be documented more explicitly (ie that
it behaves like Class.getResource, not ClassLoader.getResource).

Then, this could be deprecated, and we could make a prefered variation
of getResource which doesn't take a class argument, just a resource
path, and it would simply behave as the existing
ClassLoader.getResource. From what I know, except in Java 1.1, the
context classloader is always safe to use. (do we need Java 1.1
compatibility here?)

Then there is the question of classPackageAsResourcePath, which I
originally wrote, but actually is only really correct when then used to
call the current ClassLoaderUtils.getResourceAsStream or
Class.getResourceAsStream. At a minimum, it should be documented, but I
think it would be cleaner to not have it prepend a leading slash at all,
so it could be fed to the regular ClassLoader.getResource.

Finally, I think it possibly breaks the principal of least surprise that
in most places (like ClassPathXmlApplicationContext or the web xml
application context), we take resource paths and assume that
    a/b/c/d/123.abc
is the same thing as
    /a/b/c/d/123.abc

That is not how ClassLoader.getResource treats things, and that's not
how Class.getResource treats things, so why are we doing it? At a
minimum, it should be strongly documented, but I think it's simpler to
just accept the first form only, to be like classloader resource
specifications in other java apps/libs. This would obviously break some
existing code. In fact, we even usually add the leading / right now
automatically if it's not there.

What do you guys think?






-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer