Brett Bergquist wrote:
> Craig, you mention that a container is not required to run your web
> application out of filesystem, but could run it out of a JAR, etc. and
> mention to use getResource and getResourceAsStream. Now I do this for
> anything that I need read-only support, but what if a web application needs
> read-write support for things such as data files, etc. I would prefer that
> these files be part of the installed web application. What would a
> container do in these cases.
>
Unfortunately, not much at the moment :-(.
I suspect most containers will give you a read-only URL back from the
ServletContext.getResource() method, and there is no way to ask for an output
stream *to* a resource.
Portable support for read/write resources was one of the topics that was
discussed by the JSR-053 expert group (the committee that created the servlet
2.3 and JSP 1.2 proposed final draft specs). However, there was nothing close
to consensus on how this issue (or a whole bunch of related issues about
resources, such as "how can a web app ask for the last modified date/time of a
resource?") should be handled -- so it got punted into "fixed in next rev"
status.
For the time being, the recommended approach to storing application data
persistently (that is, across server restarts) is to use a database, an EJB, a
directory server, or some other similar mechanism.
>
> Thanks for your insight.
>
> Brett M. Bergquist
>
Craig McClanahan
PS: The option to run a webapp directly out of the WAR file is one of the
features I want to see implemented in Tomcat 4.x at some point. Because the
list of resources is fixed, I can easily forsee an environment where you cache
them all in memory -- and Tomcat 4.x can already serve in-memory resources
pretty much as fast as a web server like Apache can serve file-based ones.
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 02, 2001 5:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: getRealPath("/") and getRealPath("")
>
> chris monster wrote:
>
> > apologies if i have missed a previous posting in my searches.
> >
> > in cross-testing our webapp between Tomcat 3.1 and another container
> > (Resin 1.2.1) for compliance, i noticed that the behaviour of
> > ServletContext.getRealPath() is different when applied to the
> > application root. ( actually, after checking the 2.2 spec, i suspect
> > this may not be well defined. )
> >
> > for getRealPath("/") AND getRealPath("")
> >
> > Tomcat 3.1 returns:
> >
> > realpath/
> >
> > whereas the other container returns:
> >
> > realpath
> >
> > (without the trailing path-separator)
> >
> > i'm coding around this difference right now, but i'm curious who i
> > should be bugging about this. (get it, 'bugging'? ;)
> >
>
> Since this would be a spec interpretation issue, the best place to send
> "bugging" messages would be to the spec feedback address printed on the
> front of
> the servlet spec:
>
> [EMAIL PROTECTED]
>
> Tomcat (and every other container) should implement what the spec says. If
> the
> spec is silent on a particular issue, then the appropriate thing to do would
> be
> lobby for clarification in the next version -- which is timely now, because
> the
> Servlet 2.3 spec is currently in "proposed final draft" stage, not "final".
>
> >
> > chris monster
> >
>
> Craig McClanahan
>
> PS: As a side issue, I would encourage web app developers to start using
> ServletContext.getResource() and ServletContext.getResourceAsStream(),
> instead
> of ServletContext.getRealPath() followed by file I/O, to access internal
> resources. The reason for this is that a servlet container is *not*
> required to
> run your web app out of a filesystem (as Tomcat currently does) -- it may
> run
> them directly from a JAR file, or in an environment like Oracle's where the
> web
> app's resources are actually BLOB objects stored in a database, rather than
> being accessible as files.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
