> -----Original Message-----
> From: Jim Carlson [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 04, 2003 3:07 PM
> To: Tomcat Users List
> Subject: Re: WAR format question
>
>
> Thanks. This answers my question, but I'm still left with the
> impression that I'll need to go beyond the WAR format if I
> want to write
> to a log or flat file DB (i.e., non-temp application file).
> Also, since
> containers don't guarantee support for an unpacked WAR (are there any
> containers that truly don't support this?), putting conf files that
> change after deployment in the WEB-INF seems a little
> sketchy. At the
> minimum, it adds the hassle of extracting and re-archiving
> the conf file
> to every edit.
> My impression is that WAR was designed around the best-practices
> scenario of having web app instances that don't save local
> state to the
> filesystem, but use a DB or some J2EE storage mechanism, for ease of
> clustering. Such apps would probably get their conf from a
> JNDI resource.
> However, I still think that the correct location for log files is
> resolved in this scenario. Those of you using WAR along with
> file logs
> -- where do you put them?
I think the intent of the spec writers was that you use the built-in
logging facilities and leave it up to the appserver to decide where to
put them. Tomcat has pretty flexible logging support, allowing you to
log everything to one file, have per-context logs, etc.
If you really need your own log, I'd recommend making the location a
context-param.
--
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863
>
> Thanks,
> Jim
>
>
> Jacob Kjome wrote:
> >
> > Put stuff that isn't supposed to be accessed via the web under
> > WEB-INF.
> > You can create whatever directory structures you want within that.
> >
> > In order to obtain access to a file under WEB-INF in a completely
> > portable way, use something like...
> >
> >
> getServletContext().getResourceAsStream("/WEB-INF/myproperties.xml");
> >
> > As far as writing stuff to your webapp, there is no
> guarantee that you
> > have access to the file system other than a temporary directory
> > designated for your webapp by the servlet container. You only have
> > access under Tomcat because, by default, it exploded .war files to
> > directory structures and then serves the directory
> structure. However,
> > webapps can be deployed entirely from a .war file, in which
> case you
> > can't use File IO within the application structure. I am acutally
> > looking for a way to be able to write directly into an
> archive such as a
> > .war file. If you happen on any info on that I would love
> to know about
> > it.
> >
> > Check out the servlet api. You may be surprised to find a lot of
> > methods like this that make dealing with webapps quite easy.
> >
> > Jake
> >
> > At 01:42 PM 2/3/2003 -0800, you wrote:
> >
> >> Hello,
> >> I have a question about the WAR directory structure.
> Namely, where
> >> is the appropriate place to put configuration files, log
> files, and
> >> other files that need to be read/written-to by my application?
> >> Clearly putting them in the webroot isn't right. Can my
> application
> >> access arbitrary files under WEB-INF? How? I know that
> conf files
> >> can be put in the classpath (e.g. WEB-INF/classes), but this seems
> >> like the wrong solution for files that will change after
> deployment.
> >> In the past, I've used the technique of creating my own
> application
> >> root, which contained a webroot/ directory in the WAR format, and
> >> pointed the servlet container at that. I used servlet
> parameters in
> >> the web.xml file to specify the location of the
> application root to my
> >> servlets, so that they could access my conf/log files. This works
> >> fine, but forces me to 'embrace and extend' the orginal
> WAR concept.
> >> Any suggestions?
> >>
> >> Thanks,
> >>
> >> Jim Carlson
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
