After doing some more investigation, I've found the following.

If the webapp is not present when Tomcat is started, but webapps/MyApp.xml 
exists, the <Context> in the xml file will be added to server.xml when MyApp 
is deployed.  Although the <Context> is added to server.xml, the deploy 
fails, reporting "Application already exists at path /MyApp"--in other 
words, the configuration for the application is present but the app itself 
isn't.

In order to get MyApp.war onto the server, it's necessary to undeploy the 
webapp, which removes the <Context> from server.xml, and deploy it again... 
except the new deployment ignores the <Context> in MyApp.xml and uses only 
the defaults in the webapp's web.xml file.

So it's a Catch-22 situation: either you have the local configuration and no 
app, or the app and no local configuration.

(This is all with 4.1.4; the release notes in 4.1.5 don't seem to indicate 
any changes that would affect the behaviour.)

Peter J.

Peter Janes wrote:
> Oops... it *was* actually there, I just snipped it accidentally while 
> making the file more generic for the list.  The actual <Context> tag 
> I've been using is:
> 
> <Context path="/MyApp" 
> docBase="../work/Standalone/localhost/manager/MyApp.war" debug="1" 
> cookies="false" override="true">
> 
> I've also tried docBase="../work/Standalone/localhost/LG.war", since the 
> app isn't actually part of "manager".
> 
> (Also, because I didn't include the information before, I'm using Tomcat 
> 4.1.4 under Java 1.4.)
> 
> Thanks,
> Peter J.
> 
> Jacob Kjome wrote:
> 
>> Hello Peter,
>>
>> You have no appBase attribute on your <context> element.  You need to
>> point that to your deployed directory or .war file.
>>
>> Jake
>>
>> Monday, June 17, 2002, 1:46:04 PM, you wrote:
>>
>> PJ> I seem to recall that remotely-deployed web apps can be configured 
>> locally PJ> starting in the Servlet 2.3 spec.  (Unfortunately I can't 
>> find chapter and PJ> verse at the moment.)  The gist is that a config 
>> fragment is placed in the PJ> webapps directory with the same basename 
>> as the path, and this would be used PJ> as well as/instead of the 
>> .war's embedded web.xml.  In fact, I can see this PJ> being done for 
>> the "manager" webapp, which is locally configured in PJ> 
>> ${CATALINA_HOME}/webapps/manager.xml.
>>
>> PJ> I'd like to be able to do this with my own application, but 
>> haven't had any PJ> luck.  I'm trying to add an init parameter, "foo", 
>> and redirect the app's PJ> log messages to its own file.  Presuming 
>> the path is "/MyApp", I have the PJ> following config fragment in 
>> ${CATALINA_HOME}/webapps/MyApp.xml.
>>
>> PJ> <Context path="/MyApp" debug="1" cookies="false" override="true">
>> PJ>          <Parameter name="foo" value="bar" override="true"/>
>> PJ>          <Valve className="org.apache.catalina.valves.AccessLogValve"
>> PJ>                  prefix="MyApp." suffix=".log" pattern="common"/>
>> PJ> </Context>
>>
>> PJ> I've tried turning debug on and off, setting override to true and 
>> false (is PJ> it just me, or does the double-negative in the 
>> deployment descriptor PJ> documentation confuse anyone else), and 
>> enabling various combinations of the PJ> Parameter and Valve elements, 
>> and completely restarting the server, all with PJ> no luck.
>>
>> PJ> It seems unlikely, but do I need to create a 
>> ServletContextListener or PJ> ServletContextAttributeListener to pick 
>> up the extra init parameters?
>>
>> PJ> Is there (hopefully) some fundamental step I've missed?
>>
>> PJ> Thanks,
>> PJ> Peter J.
>>
>>
>>
> 
> 


-- 
fix, n., v.  What one does when a problem has been reported too many
times to be ignored.
   --The New Hacker's Dictionary, 3rd ed.


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

Reply via email to