DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2003-06-24 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
Version|Nightly Build   |5.0.3



--- Additional Comments From [EMAIL PROTECTED]  2003-06-24 22:50 ---
Improvements have been made to Tomcat 5.0 deployer, which should address this
RFE. This will be in Tomcat 5.0.4.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-07-15 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly





--- Additional Comments From [EMAIL PROTECTED]  2002-07-15 13:56 ---
Dear Remy

You have my full sympathy about this problem, but there is a lot of confusion 
occurring.

You're being perfectly reasonable both in pointing out that this isn't a bug at 
all, but the designed behavior, and in suggesting that bug reporters instead 
submit a patch to change the behavior.

The problem is that many people who are experiencing this bug, and this applies 
to me, are not technically adept enough to propose such a change - is there any 
chance that you could revisit the stated design and , or would this then 
contravene a specification?

What I believe people want or need is to be able to start Tomcat *with* a 
context (e.g. MyApp) defined in server.xml, and with a MyApp.war file in 
place, but *without* the exploded MyApp webapp directory; in this scenario it 
would be most excellent if Tomcat unpacked the WAR before alternatively 
discovering the absence of the declared context.

What are your thoughts on this suggestion?

TIA

Kind regards
Tim Cooke
P.S. At present I run Tomcat 4.0.1.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-06-05 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-06-06 01:07 ---
*** Bug 6739 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-04-23 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-04-23 15:01 ---
*** Bug 8418 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-04-12 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-04-12 23:05 ---
*** Bug 8036 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-03-22 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly





--- Additional Comments From [EMAIL PROTECTED]  2002-03-22 18:36 ---
I have also observed this behavior. This probably could be considered more of a 
bug in the documentation than the code. The 4.0 on-line docs state you can set 
(the unpackWARS attribute of a Host element) to true if you want web 
applications that are deployed into this virtual host from a Web Application 
Archive (WAR) file to be unpacked into a disk directory structure. They also 
state that (y)ou can nest one or more Context elements inside this Host 
element, each representing a different web application associated with this 
virtual host.

As to Context, (t)he Context element represents a web application, which is 
run within a particular virtual host. Each web application is based on a Web 
Application Archive (WAR) file, or a corresponding directory containing the 
corresponding unpacked contents..., and that(e)ach (Context element) MUST 
have a unique context path, which is defined by the path attribute.

The docs don't say that before Tomcat unpacks any warfiles, it will first 
attempt to verify the context path of a Context element by checking for a 
web.xml file in the corresponding webapp WEB-INF directories. It also doesn't 
state that if it can't find the web.xml file in the context path directory 
referenced by the Context element, it will shut down.

If anything, the desired behavior should be the opposite: unpack the warfiles, 
then check the Context elements in server.xml against the appropriate 
web.xml. That might be a little less irritating than not.

PaulGarvie

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-03-06 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-03-06 23:30 ---
*** Bug 6941 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-02-15 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-02-15 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly





--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 03:21 ---
[Note that this is still the behaviour in 4.0.2].

I must concur with the reporter.  The documentation at tomcat-
docs/config/host.html leads one to believe that the auto-deployment of the 
application is orthogonal to the automatic creation of the context if it is 
not supplied. 

A work-around we have experimented with is to choose a path that is different 
from the docBase (given that documents.war is in the webapps directory):
Context path=”/docs” docBase=”documents”/
At first this seems to work but there are two problems
1. This actually deploys as two applications, each using the same docBase.  
Once at /docs and the other at /documents.
2. There is a race condition.  If the “/doc” context is started before the 
documents.war is deployed it will not be found until tomcat is restarted.

It does not seem unreasonable to want to have a war file auto deploy and 
specify a context in the server.xml file.  I may have an application for 
which I wish to create files in the applications docBase and want to add 
parameters to the context (e.g. realm.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-02-15 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Critical|Enhancement
   Priority|Other   |Medium
Version|4.0.1 Final |4.0.2 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-02-16 07:04 ---
As I stated quite a few times, this bug will not be fixed.
If you are not satisfied with the current behavior, the best way to fix it is to
submit a patch, and we'll consider it for inclusion.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2002-01-02 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-01-02 06:36 ---
*** Bug 5600 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-28 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly





--- Additional Comments From [EMAIL PROTECTED]  2001-11-28 09:10 ---
*** Bug 5105 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-27 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2001-11-27 11:55 ---
*** Bug 5105 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-16 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2001-11-16 00:38 ---
Yeah, it does work ONLY if the webapp is in extracted form under webapp/lexis...

BUT the examples webapp is now NOT distributed as a war-file. It was so 
distributed in earlier Versions. Tomcat 3.2.1 had some war-files: admin, 
examples, ROOT and test. With Catalina these webapps aren't distibuted anymore 
as war-files.

May this be because of this problem, or should we developers avoid using war-
files to distribute our applications/updates?

Please take a closer look to the following:
==
WHEN I DO NOT DEFINE A CONTEXT FOR lexis, BUT A DefaultContext,

  Host name=localhost debug=0 appBase=webapps unpackWARs=true

Valve className=org.apache.catalina.authenticator.SingleSignOn
   debug=0/
Valve className=org.apache.catalina.valves.AccessLogValve
 directory=logs  prefix=localhost_access_log. suffix=.txt
 pattern=common/

Logger className=org.apache.catalina.logger.SystemOutLogger/

DefaultContext reloadable=true
  Manager className=org.apache.catalina.session.PersistentManager
  debug=4
  saveOnRestart=false
  maxActiveSessions=-1
  minIdleSwap=-1
  maxIdleSwap=-1
  maxIdleBackup=-1
Store className=org.apache.catalina.session.FileStore/
  /Manager
/DefaultContext
.

THE WAR FILE webapps/lexis.war WILL BE EXPANDED AND DEPLOYED.
BUT THIS DEFAULT CONTEXT WILL JUST BE IGNORED (saveOnRestart=false).
I AM ALSO NOT ABLE TO DEFINE APPLICATION PARAMETERS:
==
Starting service Tomcat-Standalone
Apache Tomcat/4.0.1
StandardHost[localhost]: Installing web application at context path /lexis from 
URL jar:file:D:\Programme\JBuilder5\tomcat\webapps\lexis.war!/
WebappLoader[/lexis]: Deploying class repositories to work directory 
D:\Programme\JBuilder5\tomcat\work\localhost\lexis
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/activation.jar to 
D:\Programme\JBuilder5\tomcat\webapps\lexis\WEB-INF\lib\activation.jar
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/crimson.jar to 
D:\Programme\JBuilder5\tomcat\webapps\lexis\WEB-INF\lib\crimson.jar
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/jaxp.jar to D:\Programme\JBuilder5
\tomcat\webapps\lexis\WEB-INF\lib\jaxp.jar
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/lexis.jar to 
D:\Programme\JBuilder5\tomcat\webapps\lexis\WEB-INF\lib\lexis.jar
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/log4j.jar to 
D:\Programme\JBuilder5\tomcat\webapps\lexis\WEB-INF\lib\log4j.jar
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/mail.jar to D:\Programme\JBuilder5
\tomcat\webapps\lexis\WEB-INF\lib\mail.jar
WebappLoader[/lexis]: Deploy JAR /WEB-INF/lib/struts.jar to 
D:\Programme\JBuilder5\tomcat\webapps\lexis\WEB-INF\lib\struts.jar
StandardManager[/lexis]: Seeding random number generator class 
java.security.SecureRandom
StandardManager[/lexis]: Seeding of random number generator has been completed
StandardManager[/lexis] IOException while loading persisted sessions: 
java.io.WriteAbortedException: Writing aborted by exception; 
java.io.NotSerializableExce
ion: org.apache.log4j.Category
java.io.WriteAbortedException: Writing aborted by exception; 
java.io.NotSerializableException: org.apache.log4j.Category
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:445)
at java.io.ObjectInputStream.inputClassFields
(ObjectInputStream.java:2263)
at java.io.ObjectInputStream.defaultReadObject
(ObjectInputStream.java:519)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1412)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.inputClassFields
(ObjectInputStream.java:2263)
at java.io.ObjectInputStream.defaultReadObject
(ObjectInputStream.java:519)
at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1412)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
at org.apache.catalina.session.StandardSession.readObject

DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-16 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly





--- Additional Comments From [EMAIL PROTECTED]  2001-11-16 02:08 ---
I have test the DefaultContext with nightly 11/12/2001 build
and it works with Parameter and Env

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-15 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 13:34 ---
We had already tried your proposal, but it does not work.

We have not changed the parameter unpackWARs (which -I think-
is responsible for the unpacking), but Tomcat does not unpack the
webapp:

Host name=localhost debug=0 appBase=webapps unpackWARs=true

Is there any other way to let Tomcat extract the WAR file?

We _must_ define a context for lexis, to do the folowing:
1) avoid the sessions to be persisted and reloaded (saveOnRestart=false) when 
Tomcat is shut down and restarted (Just because we do not only use struts: we 
also use log4j, which is not Serializable, and at higher levels the 
PersistentManager declarations seem not to work)
2) to log4j the lexis application to a specific file/directory
3) to use application parameters

((Without defining a context for the webapp lexis Tomcat
DOES extract the WAR file. Only when I __define__ a context
it DOES NOT!!))

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-15 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2001-11-15 14:14 ---
What I suggest doing works for me. That's how the examples webapp is declared 
(and it uses a lot of custom parameters).

The unpackWARs attribute is used only when auto-deploying webapps, not when 
explicitely declaring contexts.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly

2001-11-13 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2001-11-13 10:57 ---
When  you use that kind of declaration (referencing a WAR), the webapp is run
without unpacking the WAR (although the JARs and the classes will be extracted
to a temporary location).
Struts should run in that mode, but webapps which require filesystem access will
not (getRealPath() will return null, and direct filesystem access to the
webapp's resources will obviously fail).

If you don't want that to happen, you can let Tomcat extract the WAR, and then
declare your context as Context path=/lexis docBase=lexis.

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]