> Thanks for the comments Craig. > > Before I continue further it might help if I put my proposal in context > by showing how customers are being virtual hosted. > > The goal is to have each customer in their own sandbox so that nothing > the customer does can compromise the security of the server, nor compromise > another customer's security. In addition, we need to empower the customers > as much as possible so that they can administer their web site and applications > without system administrators having to babysit the server or its configuration.
Glenn, A Tomcat which would be preconfigured for web-hosting company is vastly different from the needs of the other Tomcat users. Why insist to have all Tomcat users "benefit" from your security minded configuration choices ? While I reckon that the changes you propose to the deployer make sense in your use case, they add complexity for the normal users, which should be put by default with a Tomcat which would have auto everything. Instead of trying to have HostConfig do everything (and having to fight for each particular feature), I will advocate writing *alternate* HostConfig classes (at runtime, you can use the 'hostConfigClass' parameter of the 'Host' element to specify which config class should be used) which would have a more specilized behavior depending on which user category they target. I'd be happy if you contributed that, but I don't want to force feed users with webhosting oriented features (this also includes the security manager). There should be no doubt here that I definitely trust you to add modules which would make TC webhosting ready :) (Of course, it may be useful to also cleanup a bit the default HostConfig anyway) Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
