> > >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? -Dan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>