-Tim
Florian Ebeling wrote:
Hi,
This is confusing. One second after posting I found in the javadoc for ManagerServlet this: "[ManagerServlet is a] Servlet that enables remote management of the web applications installed within the same virtual host as this web application is"
Tims answere suggests, that it is not possible without further steps taken.
I tried ManagerServlet initially with two Hosts using the *same* /webapps docBase. After reading the promising JavaDoc I seperated the contents of my single webapps dir, and it seems to do what I want: listing all within each of them when pointing to the different URLs.
I could imagine that many people get confused about this, because one is tempted to think the HTTP-provided Host: header shuold be enough to distinguish. But this behaviour also makes sense in a way. How should manager be able to distinguish a stopped app from one that does not belong to this Host? I can distinguish only by switching autoDeploy off and hard-wire the contexts in server.xml. But once I use manager, I want to override these settings and add contexts dynamically. So this seems OK.
I think now, this feature is already there. Here is how my server.xml looks like (excerpt):
<Host name="localhost" debug="0" appBase="webapps_localhost"
unpackWARs="true" autoDeploy="false">
<Context className="org.apache.catalina.core.StandardContext"
path="/manager"
debug="0"
docBase="../server/webapps/manager"
privileged="true"
>
</Context>
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0"
resourceName="UserDatabase"
validate="true"/>
<ResourceLink global="UserDatabase" name="users" type="org.apache.catalina.UserDatabase"/>
</Host>
<Host name="javaroom" debug="0" appBase="webapps_javaroom"
autoDeploy="false">
<!-- <Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="javaroom" timestamp="true"/>-->
<Context className="org.apache.catalina.core.StandardContext"
path="/manager"
debug="0"
docBase="../server/webapps/manager"
privileged="true"
>
</Context>
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
debug="0"
resourceName="UserDatabase"
validate="true"/>
<ResourceLink global="UserDatabase" name="users" type="org.apache.catalina.UserDatabase"/>
</Host>
For true multi-hosting there should also be one tomcat-users.xml per Host. This would result in more GlobalNamingResources entries (which in my server.xml gets referenced -- as in the default -- by "UserDatbase").
Best regards, -Florian
Tim Funk wrote:
This lately (past 6 months) has been becoming a more common request. But the functionality is not there as distributed by tomcat. Patches welcome.
Alternatives include:
- Adding a filter to the manager app for finer grained control
- Rewriting manager to allow its namespace to be authorized via web.xml's security constraints
- Creating another webapp which does all authorization then calls the manager app via a nested HttpRequest
-Tim
Florian Ebeling wrote:
Hi there,
I wonder if there is any means to give users access to the manager application, but let them only manipulate contexts located within their own virtual <Host>s?
I think this question is one every ISP has to stumble across, provided he doesn't want to get "please restart ..." mails all day long and restart them manually.
I got a bit angry with my provider because he offers "Java server," but he thaught JSP was everything there was to it. When I told him about Contexts he was not really prepared. Still he's willing to solve it. So I tried to figure it out by googling, browsing mail archives, etc. But, it has not yet become apparent to me how ISPs are supposed to set up tomcat4 to serve several virtual hosts. I told him to define one Host for me and he did so. It works, but this is not really sufficient for an ISP. It is unclear to me how to deploy and reload applications remotely, in a by-host manner.
Is there a tomcat-based solution out there, or is it necessary to work around it, somehow? (For example by invoking a small script local to the server via some custom "admin" page link, or something.)
--------------------------------------------------------------------- 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]
