tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan>
Subject Re: SSI Servlet has big problems
Date Fri, 03 May 2002 21:58:41 GMT
>Dan Sandberg wrote:
>>I'll be done with the SSI rewrite tomorrow.
>>I'd like to get the community's advice on a number of issues:
>>1-I changed the names of the files from Ssi... to SSI...  This seems to
>>be more consistent with the naming scheme of other files, and made
>>things easier for me since I did a gradual rewrite of everything.  This
>>will make it harder to see what I changed when I submit a diff,
>>however.  I changed 75% of everything, so I'm not sure this matters.  Is
>>it ok?
>Thats fine, please put the SSI servlet code into a sub package in servlet
>also.  i.e. org.apache.catalina.servlet.ssi.*.

Write now the servlet (one class) is in: org.apache.catalina.servlets
While all its supporting classes are in: org.apache.catalina.util.ssi

I propose moving all the SSI support classes to: org.apache.catalina.ssi

They don't belong in servlet, since they CAN be used without a servlet ( 
for example, in a filter ) and they prob. don't belong in util, since 
they can't be used by anything other than the SSIServlet, and the SSIFilter.

>>2-What's the story with the SSI jar having the .renametojar extension?
>> I'm surmising that this is because this class will be loaded under the
>>system class loader rather than the user servlet class loader, causing
>>the #exec functionality to be a security risk.  Can't we just have a
>>directory where we put servlets that should be loaded under the 'safe'
>>class loader?
>Yes, this is so SSI can not be used without the admin explicitely enabling
>it by renaming the jar.  Whether the Runtime.exec() method can be called
>is dependent upon the catalina.policy, not on what ClassLoader is used.
>I have proposed a reorganization of the servlets into sub packages in
>org.apache.catalina.servlets.  In addition moving the jar files for the
>servlets into a separate directory. /server/servlets for those which require
>access to privileged internal catalina code, and /shared/servlets for those
>which do not require access to privileged catalina code.
Sounds good.  Why is this not a problem with JSP pages then?  How is 
doing an exec in SSI different than doing a Runtime.exec in JSP?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message