What I think you're saying, Costin, is that ServletContext.getResource does
the same thing that ClassLoader.getResource does except that
ServletContext.getResource does not necessarily have access to the same
resources to which ClassLoader.getResource has access. The servlet engine
defines what resources ServletContext.getResource can access.
And...if that's roughly the definition that the Servlet API group intended
then I think maybe the spec itself is what's confusing people since the spec
says....
"This method does not fill the same purpose as the getResource m method in
java.lang.Class. The method in java.lang.Class looks up resources based on
the
Class's class loader. This allows the server to make content visible to any
servlet
from any source without regard to class loaders, location, etc."
...It's the "This method does not fill the same purpose as the getResource
method in java.lang.Class" part that I think is confusing. Really the
semantics of the two methods are roughly the same: "Find the denoted
resource and return a complete URL to it".
ted stockwell
> -----Original Message-----
> From: Costin Manolache [SMTP:[EMAIL PROTECTED]]
>
> I know everyone will tell me I'm wrong again, but it seems getResource()
> might have a more "static" meaning.
>
> Most of the time people use ClassLoader.getResource() to get various
> files in classpath.
>
> RequestDispatcher "sounds" like a method to get a resource available
> on the server ( be it simple file or any kind of exe), getResource()
> should be
>
> specific to the servlet engine environment ( otherwise it will be
> confusing
> for people
> using ClassLoader.getResource() and expect it to get a file that is in the
> classpath.
> Using the same name and very close semantic is allways confusing)
>
> getResource() might have a dynamic content, but if you can't pass
> parameters
> you don't get too many advantages. RequestDispatcher at least allows you
> to
> pass parameters
> ( even if you are not allowed to anything but forward the parameters you
> got),
>
> adding parameters to getResource() will sound strange.
>
> I'm just a confused user,
> Costin
>
>
>
> > The first thing is - as I understand it - getResource() is there to
> > be used by Servlet programmers and it may be legitimate for them to
> > get the contents of resources by requesting a particular file.
> >
> > IMHO:
> > RequestDispatchers are for when you want to deal in a specific way
> > with executable content (ok - exe tied to a resource that is
> > conceptually just a resource).
> >
> > getResource() is a more general method which may be exported by a
> > servlet into a different programming enviornment. getResource() is the
> > far easier method to understand for the non-servleteer. I can conceive
> > of add ons to servlet engines that use getResource to present
> > management pages for example.
> >
> > Therefore it might be quite legitimate for a server to do
> > getResource("/somepath/file.ext");
> >
> > Where a servlet SomeServ is mapped to the path: /somepath
> >
> > The file.ext part may be what is required syntactically by SomeServ.
> > Who knows?
> >
> > I suspect that we may see the API going down this route and
> > eventually getting rid of RequestDispatchers since it makes the "I'm
> > just a resource perhaps generated on the fly by a servlet" more
> > explicit.
> >
> > I am not actually trying to use getResource() myself. Just implement
> > it in my Servlet engine.
> >
> > What I was really trying to get to the bottom of is whether you could
> > call getResource() on another path outside of the context engine and
> > expect to get a legitimate result.
>
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
