tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Panzhin <jalex...@balticum-tv.lt>
Subject Re: Challenges for Java hosting
Date Fri, 07 Apr 2006 05:37:48 GMT
Write you own SecurityManager.
http://java.sun.com/docs/books/tutorial/essential/system/writingSMgr.html

> I have one suggestion regarding tomcat and security
> manager, but I don´t know if it fits here. We have a
> huge problem managing security configuration (i.e.
> catalina.policy). We have a common base policy and an
> entry for each virtual host. Sometimes clients put
> unmanaged libraries that require special permissions.
> We have to reinitialize the JVM to make these
> permissions take effect.
>
> Thanks
> Renato
>
> --- Remy Maucherat <remm@apache.org> wrote:
>
>   
>> Hi,
>>
>> This thread started (for whatever reason) on the
>> private list as part of 
>> an unrelated discussion. The point is to see what
>> could be improved to 
>> make Tomcat more suitable for shared hosting, which
>> is a very nice goal, 
>> but unfortunately with very serious issues.
>>
>> I don't see many improvements possibilities, as I
>> consider the following 
>> solutions and problems (where each user would at
>> least need its own vhost):
>> - Every virtual host gets its own appBase folder.
>> Having its own folder 
>> for JARs just won't work (or it means you were able
>> to use the "shared" 
>> folder successfully, which I doubt). If you use the 
>> TOMCAT_HOME/TOMCAT_BASE stuff, each user can get its
>> own "shared" folder.
>> - There are still tons of JVMs to manage and
>> monitor, which may be a 
>> problem.
>> - If the connector should be shared, with the
>> servlet containers running 
>> in separate processes, I don't see how to cross the
>> process barrier 
>> except by going back to square one (httpd in front,
>> with AJP and many 
>> JVMs/Tomcats, each with its own vhost).
>>
>> Some general problems for production are:
>> - No self tuning of the JVM.
>> - No actual isolation, throttling capabilities, etc,
>> provided by the JVM.
>> - Impossibility to control memory leaks (impossible
>> to force discarding 
>> classloaders and all associated class defs and
>> instances, for example).
>> - Hard to do thread management (by that I mean,
>> monitor and recover for 
>> threads stuck in loops or deadlocked).
>>
>> Any ideas ?
>>
>> I suppose native code could be used to improve the
>> situation in some 
>> areas (although I don't know how to do it ;) ).
>>
>> Rémy
>>
>>
>>     
> ---------------------------------------------------------------------
>   
>> To unsubscribe, e-mail:
>> dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail:
>> dev-help@tomcat.apache.org
>>
>>
>>     
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>   


Mime
View raw message