tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup mbeans-descriptors.xml
Date Wed, 04 Aug 2004 20:09:06 GMT

----- Original Message -----
From: "Remy Maucherat" <>
To: "Tomcat Developers List" <>
Sent: Wednesday, August 04, 2004 12:19 PM
Subject: Re: cvs commit:
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup mbeans-descriptors.xml

>Bill Barker wrote:
>>"Remy Maucherat" <> wrote in message
>>> wrote:
>>>>billbarker    2004/08/03 23:48:07
>>>> Modified:    catalina/src/share/org/apache/catalina/startup
>>>>              mbeans-descriptors.xml
>>>> Log:
>>>> Adding methods for JMX managed Contexts.
>>>> -- Adding method to get the configBase via JMX
>>>> -- Adding methods to add and remove apps with minimal dependancy
>>checks.  This is for use with JMX apps (like the admin) that control the
>>Context themselves.
>>>I don't quite see how this is any different from check(String name).
>>Well, for 'add', there isn't necessarily any context.xml file, and there
>>isn't necessarily any relationship between the Context path and docBase.
>>For 'remove', the remove is unconditional and doesn't require touching
>>resources that may have never existed.
>>One alternative would be to have the admin webapp alway create context.xml
>>for the "Create Context" action, and delete it for the "Remove Context"
>>action.  However, this creates way more problems then it will ever solve
>>least with the config as it is now).
>Yes, why not.
>To be perfectly honest, I envisioned that these manager/admin/etc would
>indeed create the needed context.xml file (or the folder or war in the
>docBase; you get the idea). The most important thing is that all
>deployment operations are fully handled by one component (otherwise, we
>fall back in the previous situation where the auto deployer doesn't talk
>to the deployer, which doesn't know about the manager webapp). The new
>methods don't change this, so it's not a problem.

The way that the admin works at the moment, any change you make only affects
the currently running instance of Tomcat unless you hit the "Commit Changes"
button.  With my patch, that doesn't change.  If I create the context.xml
file when you do a "Create Context" action, then you will still have that
Context defined next time Tomcat is started, even if you didn't do a "Commit
Changes".  Even worse is that if I delete the context.xml file when you do a
"Delete Context" action, then your Context is still gone the next time
Tomcat is started.

That being said, I'm +-0 on the issue as a whole (the admin is one of the
first things I remove when installing Tomcat :).  I can change the admin to
use check(String) if people think that admin should work like manager.
However, I'm going to be without computer access through the weekend, so it
will have to wait until next week.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message