On Mon, Jan 12, 2004 at 11:43:44AM -0700, George Sexton wrote: > 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.
This is ok, no reason why the uber-tomcat-admin can't have just one place to do this. > 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? Strong -1. Its there and it is being used, and there will continue to be a need for it even if the admin app supports the types of things the manager does. There are many who use the ant tasks to manage webapps, especially during web application development. The ability to delegate out web application mangement and deployment to a customer for only a single virtual host is crucial for those who administer instances of Tomcat which support multiple customers in multiple virtual hosts. Including the ability to deploy a web application via the HTML manager. Regards, Glenn > > -----Original Message----- > From: Remy Maucherat [mailto:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]