Re: [Springframework-developer] FileSystemXmlApplicationContext.getResourceByPath

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

Btw, unfortunately the fact that FileSystemXmlApplicationContext treats 
what should be absolute (starting with a leading /) as relative is a 
historical thing... I picked this up a long long time ago, probably a 
bit past Spring 1.0, but at that time it was decided that it would not 
be changed in order to not break backwards compatibility, but it's an 
unfortunate wart, as people get surprised by it all the time. The one 
solution is to use a file: url, which will force the use of a 
UrlResource, instead of an unprefixed resource path, which will end up 
uisng a FileSystemResource, exhibiting this behaviour...

Colin

On 7/17/2006 5:26 AM, Colin Yates wrote:

> Jason,
>
> I noticed this myself and created a JIRA a while ago: 
> http://opensource.atlassian.com/projects/spring/browse/SPR-1884.
>
> Col
>
> On 17/07/06, *Jason W. Solinsky* <jso...@co... 
> <mailto:jso...@co...>> wrote:
>
>     Method getResourceByPath in FileSystemXmlApplicationContext strips
>     leading
>     "/" from paths before loading the resource (in this case the
>     context file).
>
>     The java docs explain this behavior as follows:
>
>     "Note: Even if a given path starts with a slash, it will get
>     interpreted as
>     relative to the current VM working directory. This is consistent
>     with the
>     semantics in a Servlet container."
>
>     Shouldn't servlet specific semantics be implemented by servlet
>     specific
>     classes? (Note that the WebApplicationContexts do not appear to extend
>     FileSystemXmlApplicationContext [anymore?]).
>
>     As a consequence of this behavior, Unix paths beginning with "/"
>     become
>     relative, but Windows paths beginning in "C:\" remain absolute. We
>     have
>     temporarily gotten around this by inserting an extra "/" in front
>     of every
>     path that we use to configure the FileSystemXmlApplicationContext,
>     but this
>     seems like a horrible hack.
>
>     Thanks to Spring's wonderful design, we can easily create our own
>     subclass
>     that avoids this behavior, but shouldn't the servlet specific
>     functionality
>     be removed from this method altogether?
>
>     Thanks,
>
>     JWS
>
>
>
>     -------------------------------------------------------------------------
>
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>     _______________________________________________
>     Springframework-developer mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>------------------------------------------------------------------------
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>