unpackWars performance/advantages/disadvantages?

[Dennis Muhlestein <de...@zserve.com>]

Great, thanks for the response.

I'd like to know if anyone has experience with deploying war files and
then setting unpackWARs to false.

Is there any advantage/disadvantage to doing this?  Why would one want
to?  How does this affect performance?  Any reasons for choosing one
over the other?

Thanks
Dennis

On Thu, 2002-09-12 at 14:11, Nome real wrote:
> That's the new behaviour for 4.1.x. See the RELEASE-NOTES.
> 
> 
> On 12 Sep 2002 08:12:34 -0600, Dennis Muhlestein <de...@zserve.com> escreveu :
> 
> > De: Dennis Muhlestein <de...@zserve.com>
> > Data: 12 Sep 2002 08:12:34 -0600
> > Para: tomcat-user@jakarta.apache.org
> > Assunto: Tomcat 4.1.10 and symbolic links (linux)
> > 
> > I've found many references to this problem on the list and in mail
> > archives but none had to do with my situation and I don't know how to
> > fix this.
> > 
> > Because we have used other web containers in the past, our WEB-INF
> > folder is not located in the root of the webapp.  We have a symbolic
> > link.  The directory structure looks like this.
> > 
> > ROOT/
> > ROOT/docs  (jsp images etc)
> > ROOT/WEB-INF/
> > ROOT/classes/
> > ROOT/jars
> > 
> > There are sym links to make this work with tomcat.
> > 
> > ROOT/docs/WEB-INF-> ../WEB-INF
> > ROOT/WEB-INF/classes-> ../classes
> > ROOT/WEB-INF/lib-> ../jars
> > 
> > 
> > This all worked fine with tomcat 4.0.4 but now with 4.1.10 I can't get
> > it to recognize the web.xml  I get the following:
> > 
> > ContextConfig[]: Missing application web.xml, using defaults only
> > 
> > 
> > If I remove the sym links and copy the data to the correct location,
> > things start up, the web.xml is found.
> > 
> > Is it just symbolic links in general or is there something I'm missing.
> > Thanks for any input.
> > 
> > -Dennis
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>