|
From: Rod J. <rod...@in...> - 2003-05-06 17:37:39
|
I'm also getting a failure with the previous
/WEB-INF/applicationContext.xml.
What's the recommended form now? No leading slash failed also, so I haven't
been able to start my application.
The error message should also include the location, e.g. "Location '" +
location + "' isn't a URL...
2003-05-06 18:27:34,685 ERROR
com.interface21.web.servlet.ControllerServlet - <S
ervlet with name 'test' : initialization error>
(HttpServletBean.java.init:113)
ApplicationServerThread
com.interface21.context.ApplicationContextException: IOException parsing XML
doc
ument for application context with display name [WebApplicationContext for
names
pace 'test-servlet']; nested exception is:
java.io.FileNotFoundException: Location isn't a URL and cannot be
interp
reted as (file) path
java.io.FileNotFoundException: Location isn't a URL and cannot be
interpreted as
(file) path
Regards,
Rod
----- Original Message -----
From: "Chris Smith" <ch...@lo...>
To: "jürgen höller [werk3AT]" <jue...@we...>
Cc: <spr...@li...>
Sent: Monday, May 05, 2003 12:49 PM
Subject: Re: [Springframework-developer] spring-web broken on unix
> Hi Juergen,
>
> Yes, that's much neater. I forgot you could use a URL to load a file
> and agree about keeping the number of config parameters down.
>
> Regards,
> Chris
>
> jürgen höller [werk3AT] wrote:
>
> >Hi Chris,
> >
> >You're right, this can easily lead to confustion on Unix platforms. We
need a more convenient solution.
> >
> >I don't want to introduce yet another config parameter, so I've applied a
more general change. From the beginning, I've planned to support plain
absolute file paths as a convenience, not as a major feature. Given the
current problematic interpretation of file paths, I've removed
AbstractApplicationContext's absolute file path support altogether,
replacing the getResourceByRelativePath template method with
getResourceByPath.
> >
> >This means that an ApplicationContext implementation can interpret any
non-URL path any way it wants, not just relative file paths.
AbstractApplicationContext's default implementation treats it as (absolute
or relative) file path now, XmlWebApplicationContext generally as
ServletContext resource (no matter if relative or not),
ClassPathApplicationContext as classpath resource (always interpreting as
root path, not relative to the class).
> >
> >Note that absolute file paths can still be accessed easily by using a URL
like "file://C:/test/test.dat", so we don't lose that capability. I consider
this clean and convenient, sacrificing non-URL absolute file path support
isn't a hassle at all. Is that appropriate for your requirements too?
> >
> >Regards,
> >Juergen
> >
> >
> >-----Original Message-----
> >From: Chris Smith [mailto:ch...@lo...]
> >Sent: Monday, May 05, 2003 11:33 AM
> >To: jürgen höller [werk3AT]
> >Subject: Re: [Springframework-developer] spring-web broken on unix
> >
> >
> >Hi Jürgen,
> >
> >I thought about suggesting using relative paths by default, but that
> >leads to a confusing situation where absolute paths are looked up in the
> >file system and relative paths are looked up in the servlet context.
> >Not to mention the fact that an absolute path on one OS can be
> >considered a relative path on another. And I don't like removing the
> >leading "/" from "/WEB-INF" as there will be plenty of people who
> >include it and end up tearing their hair out when Spring reports it
> >can't find a file that patently exists (like I did yesterday!).
> >
> >What I was going to suggest in my original email is that we have an
> >explicit param that states where a config location should be loaded from:
> >
> ><web-app>
> > <context-param>
> > <param-name>configLocation</param-name>
> > <param-value>/WEB-INF/applicationContext.xml</param-value>
> > </context-param>
> > <context-param>
> > <param-name>configLocationType</param-name>
> > <param-value>servletcontext</param-value>
> > </context-param>
> >...
> >
> >configLocationType could have the values "servletcontext" or
> >"filesystem". "servletcontext" should be the default for a web app
> >context loader, so you could omit it from the above example. This way,
> >you can control where files are loaded from explicitly, regardless of
> >whether they are relative or absolute.
> >
> >So, that's what I was going to suggest yesterday, but I wasn't sure
> >whether servlets had the same restrictions as EJBs on accessing the file
> >system. I'm sure I read it somewhere but still can't find it in the
> >servlet spec, so I guess it's ok. (If it wasn't allowed, the solution
> >would be straightforward - always load from the servlet context).
> >
> >I'm happy to code this up if you like, but you'd have to commit it.
> >
> >Regards,
> >Chris
> >
> >jürgen höller [werk3AT] wrote:
> >
> >
> >
> >>Hi Chris, Spring web users,
> >>
> >>Thanks for the report! Admittedly, I only testet this on Windows and
didn't think about Unix path names (should have come to my mind, though).
I've changed the default paths ("/WEB-INF/applicationContext.xml",
"/WEB-INF/<servlet-name>-servlet.xml") to clear relative paths now, omitting
the leading slash.
> >>
> >>On the occasion, I've made config lookup more flexible, allowing not
only for a servlet context init param "configLocation" for the root context,
but also "configLocationPrefix" and "configLocationSuffix" for namespaced
contexts (defaults are "WEB-INF/" and ".xml").
> >>
> >>Note that the trailing "-servlet" comes from the FrameworkServlet's
namespace handling and is thus part of the namespace. To override the
namespace for a specific servlet, just set a servlet init parameter
"namespace" to the desired value.
> >>
> >>Default initialization should still behave like before, and often you
won't need any customization. But if you like to, you can now customize
config lookup like this:
> >>
> >><web-app>
> >> <context-param>
> >> <param-name>configLocationPrefix</param-name>
> >> <param-value>WEB-INF/myControllers/</param-value>
> >> </context-param>
> >> <context-param>
> >> <param-name>configLocation</param-name>
> >> <param-value>WEB-INF/myRoot.xml</param-value>
> >> </context-param>
> >> <listener>
> >>
<listener-class>com.interface21.web.context.ContextLoaderListener</listener-
class>
> >> </listener>
> >> <servlet>
> >> <servlet-name>test</servlet-name>
> >>
<servlet-class>com.interface21.web.servlet.ControllerServlet</servlet-class>
> >> <init-param>
> >> <param-name>namespace</param-name>
> >> <param-value>myTest</param-value>
> >> </init-param>
> >> <load-on-startup>3</load-on-startup>
> >> </servlet>
> >></web-app>
> >>
> >>This should look up the root context file in "WEB-INF/myRoot.xml", and
the ControllerServlet context file in "WEB-INF/myControllers/myTest.xml".
> >>
> >>Regards,
> >>Juergen
> >>
> >>
> >>-----Original Message-----
> >>From: Chris Smith [mailto:ch...@lo...]
> >>Sent: Sunday, May 04, 2003 3:02 PM
> >>To: spr...@li...
> >>Subject: [Springframework-developer] spring-web broken on unix
> >>
> >>
> >>Hi everyone,
> >>
> >>Juergen, I've just found a problem with the changes you made to
> >>XmlWebApplicationContext recently.
> >>
> >>When loading the bean config in getInputStreamForBeanFactory(), it
> >>delegates to the base class AbstractApplicationContext's
> >>getResourceAsStream() method. For a config location such as
> >>"/WEB-INF/test-servlet.xml", that method will try to load it using a
> >>URL, fail, catch the MalformedURLException, then see if the path is
> >>relative or absolute. If relative, it loads it using the overridden
> >>getResourceByRelativePath().
> >>
> >>That all works fine on windows, but on unix, "/WEB-INF/test-servlet.xml"
> >>is considered an absolute path because it starts with a slash. The
> >>context fails to load because it tries to load it as a File rather than
> >>
> >>
> >>from the servlet context.
> >
> >
> >>The problem is that we can't tell whether a config location like
> >>"/WEB-INF/test-servlet.xml" is a path to a file or a resource in the
> >>servlet context. I couldn't find it in a brief flick through the
> >>servlet spec, but I didn't think servlets were allowed to access
> >>resources outside the servlet container. If that's the case, then
> >>XmlWebApplicationContext ought to override getResourceAsStream() with an
> >>implementation that always loads from the servlet context.
> >>
> >>Regards,
> >>
> >>Chris
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >>
> >>
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Springframework-developer mailing list
> >Spr...@li...
> >https://lists.sourceforge.net/lists/listinfo/springframework-developer
> >
> >
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|