On 19/08/2013 21:11, Raymond Auge wrote: > On Sun, Aug 18, 2013 at 3:36 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 18/08/2013 20:06, Raymond Auge wrote: >>> On Sun, Aug 18, 2013 at 1:59 PM, Mark Thomas <ma...@apache.org> wrote: >> >>>> First of all this is a container concern, not an application >>>> concern. Secondly, a security manager applies JVM wide. >> > > I agree 100% > > However, in this case the JSP impl is preventing the container itself from > making any such change!
No it isn't. Tomcat provides configuration options to start the container with or without a SecurityManager. Tomcat provides no options to configure the SecurityManager dynamically. > The JSP impl has no business making the decision on > behalf of either the container or JVM. The JSP implementation is part of the container. Design decisions made for one can have an impact on the other. >> <snip/> >> >>> Nowhere in any specification is this stated! >> >> Maybe not in language that is immediately clear but this is stated in >> the J2EE platform specification. (section EE.6.2.2) > > > I infer no such meaning from the EE spec. You miss my point. My point is that this is a container concern. The spec makes that clear. > Furthermore, why couldn't any of "EE.6.2.2.3 System Administrator’s > Responsibilities" be implemented as a web application designed to simplify > management of these responsibilities? They could. Tomcat does not implement that way. > As long as the policies imposed by the administrator are respected, why > does it matter where policy management takes place? It doesn't. That is a design choice for container implementers. > In fact, if I'm not mistaken one significant point for the JVM's Security > API being "dynamic" as opposed to being completely "static", is so that > management can be performed, either programmatically, or > remotely (otherwise why would these APIs even exist were that not the case). > > <snip/> > > .. none of which explains why the Jasper retains static final check of > whether security manager is enabled or not. Because Tomcat only provides options to configure a SecurityManager on start-up. If Tomcat was going to implement dynamic configuration of the SecurityManager then the various IS_SECURITY_ENABLED constants would need to be removed. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org