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

[Colin S. <col...@ex...>]

W/regards to doing something with XmlWebApplicationContext, I didn't 
realize that some containers accept paths in ServletContext.getResource 
without the leading slash. (I wish containers would just stick to the 
spec, this sort of looseness just ends confusing things and killing 
portability).

It would still be nice to get it to be able to load from the classpath 
too though. I wonder what the implications would be of just hitting 
ServletContext.getResource as the code does now, then the 
ClassLoader.getResource if the resource is not found in the first call? 
Probably it could lead to some situations where people pick up stuff 
they don't want. As far as adding a pseudo prefix to indicate classpath, 
that's an ok idea. The only issue with it is that as there is no real 
url handler in the system for that prefix, if anybody in some Java code 
tried to manipulate this as a real URL they'd get a 
MalformedUrlException as soon as they tried to construct the URL. 
However, I don't think this is an issue since in fact this value is not 
always a URL in any case.


jürgen höller [werk3AT] wrote:

>You don't need to add that slash for Hibernate's configuration file now: LocalSessionFactoryBean will automatically add the slash before passing it to Hibernate if you haven't specified it. Those checks for leading slashes were in there in all kinds of places: I've removed them everywhere besides in LocalSessionFactoryBean, as our own ClassLoaderUtils.getResourceAsStream does not need them anymore.
> 
>We could go about other libs the same way: Prepend a leading slash or remove it before passing the path to the library, adapting to the way the library needs it, so that user-specified paths will work in any case. From the point of view of a Spring configuration, either style will work, no matter if interpreted by Spring or by the library. Note that we mainly load resources ourselves and feed them to the respective library anyway: For example, for JDO and Log4J.
> 
>Regarding XmlWebApplicationContext: ServletContext.getResourceAsStream needs a leading slash according to the spec, that's why we add one if not there already. Most containers accept paths without leading slash too, though, for example Tomcat and Resin - but not Orion. It consider it generally a bit confusing that you need the slash for ServletContext, where the resource paths are interpreted as relative to the root in any case - while you must not use a leading slash for ClassLoader, where all resource paths are relative to the root too!
> 
>Interpreting paths with leading slashes as ServletContext resources and without slashes as class path resources would be confusing, IMO. As mentioned above, many web app developers might be used to be able to load from the ServletContext with no leading slash, which wouldn't work with Spring then. We shouldn't rely on such ambiguous syntactic details to decide between two completely different ways of resource loading.
> 
>Note that you can also specify URLs for ApplicationContext.getResourceAsStream, e.g. with a "file:" or "http:" prefix. So a cleaner way to support class path resources would probably be to define "classpath:" or the like as pseudo-prefix for URL-style paths. This way, there is only one meaning for non-URL paths in each context implementation, i.e. XmlWebApplicationContext always interprets them as ServletContext resource paths.
> 
>Any other opinions on this? If yes, then please voice them today - we shouldn't delay M3 any further!
> 
>Juergen
> 
>
>________________________________
>
>Von: spr...@li... im Auftrag von Colin Sampaleanu
>Gesendet: Mo 24.11.2003 00:54
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Classloading issue to resolve before M3 release!
>
>
>
>Unfortunately I don't agree that accepting both leading slashes and no
>leading slashes is going to provide the least surprise. Hibernate is
>Hibernate. If for some reason they decided to load via Class.getResource
>instead of ClassLoader.getResource, I think they're wrong (because
>they're not using the context classloader) but that's their business,
>and at least they're consistent about it. In fact, they will fail if
>they are given a path _without_ the leading slash.
>
>If we accept both to mean the same, that's ok for Spring itself, but
>it's not consistent with the fact that most other java code handles the
>two variants differently. And if you give a path to Spring, you then
>have to think, is this for Spring itself, which will handle both ways,
>or is it going to end up being fed to some lib, which needs it in one
>way, or fed to another lib, which needs it in another way, and is it
>going to be doctored by Spring, or go straight through? i.e. right now
>for Hibernate, the fact that Spring takes both formats elsewhere doesn't
>help me at all, I still have to think of Hibernate and add that slash.
>I'd rather be consistent and say, Spring needs resource paths in
>standard ClassLoader.getResource format, and that's it. Then if you have
>a case where a path is not for Spring, but is fed straight through to
>some other lib (like Hibernate), which uses Class.getResource instead of
>ClassLoader.getResource, you either strongly document this special case,
>or fix it up yourself...
>
>There is another consideration somewhat relating to this, and that is
>the fact that currently XMLWebApplicationContext is hard-coded to add
>(if not there already) a leading slash to all paths it is fed, and then
>it uses ServletContext to load the defs, so the defs can only be loaded
>off the web-context root. In this case, we could instead treat paths
>which start with a leading slash as relating to ServletContext, and
>paths which don't have a leading slash as relating to the context
>classloader, with no interference. I've always thought it was an
>unecessary limiation to not have XMLWebApplicationContext be able to
>load contexts out of the classloader.
>
>Regards,
>Colin
>
>jürgen höller [werk3AT] wrote:
>  
>