tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Sexton" <gsex...@mhsoftware.com>
Subject RE: [PATCH]Virtual Host Choice on HTML Manager
Date Mon, 12 Jan 2004 18:43:44 GMT
Here is my thinking. Of course, I am a lowly user and not a developer
but I think it pretty much covers the issues. The major issues from my
perspective are:

1)	Admin cannot deploy privileged applications. This requires
deploying manager by hand.
2)	Admin cannot stop or restart applications. This requires using
manager. 
3)	Manager already displays the status for all virtual hosts. This
kind of breaks the virtual host purity that Remy and others want in this
application.
4)	Deployment of application using manager is difficult at best. I
have never been able to do it. Even if you can do it, there are no
configuration points. IOW, you cannot configure logging.
5)	As Remy points out, people will next be asking for manager to
manage virtual hosts.

The biggest issue for me is that if you want to use a UI to manage
tomcat, 3 different tools (Admin, Hand Edit, and Manager) must be used
to create a virtual host that can be stopped and restarted. Doesn't
anyone else see a problem with this?

If I had my way, what I would do is:

1)	Add capability for admin application to stop/start/re-start
contexts. This really shouldn't be that big a deal. I cannot see any
rationale for not putting it in. Additionally, I would put the status
reports in the Admin app. If you do this, then I don't really care about
the manager application and wouldn't even deploy it all.

2)	Strip every feature except list, status, stop, and re-start from
manager. IOW, remove the deployment capability and the complete server
status feature (or limit it to the virtual host). How many people REALLY
need to script deployment of a web application? Particularly in the
limited fashion allowed by the current Manager?

George Sexton
MH Software, Inc.
Home of Connect Daily Web Calendar Software
http://www.mhsoftware.com/connectdaily.htm
Voice: 303 438 9585



-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org] 
Sent: Monday, January 12, 2004 9:04 AM
To: Tomcat Developers List
Subject: Re: [PATCH]Virtual Host Choice on HTML Manager


TANAKA Yoshihiro wrote:
> on Tue, 6 Jan 2004 16:48:47 -0600
> Glenn Nielsen <glenn@mail.more.net> wrote:
>>>I'll try to modify as follows:
>>>
>>>1)Make new classes extend HTMLManagerServlet & ManagerServlet.
>>>2)These servlets are optional. (commented out in web.xml)
>>>3)Only admin role can access them. (by web.xml)
>>>
>>>Do you think I've it figured out?
>>
>>That sounds right. :-)
> 
> I've done and put them on
> http://www.ytp.ne.jp/tech/tomcat/manager/index.html
> 
> I modified existing classes to allow them to be extended,
> but did not change their functions.
> Also I create a new build file for Deployer named 'build-muti.xml'
> cause of security.
> 
> I hope committers evaluate and commit them.

While I appreciate the effort, I don't like your patch right now, sorry
:-(

Why add complexity when it is so simple to deploy the manager webapp on 
a new host ? Note: A webapp doesn't use any noticeable amount of 
resources in TC 5 (no background thread, no nothing).
I suppose if there weren't all the changes to the default manager, I 
would have nothing against the patch (although I do hate the changes to 
the Ant tasks; it's really counter productive, and proves this is a bad 
design: the place of the vhost is in the URL).

Soon, there will be requests to add host management in the manager 
webapp, and it will become a big mess. If there's interest in improving 
the management tools, fine, but there should be a thinking process 
before the hacking starts.

Fixes were added a few days ago to the admin webapp to support dynamic 
host creation. This is a first step. It should then be possible to add a

manager to a newly created host using the admin webapp (and then you're 
done, no hacks required). The biggest problem is probably that the admin

webapp is not scriptable at all.

Rémy



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message