Fair enough! Thank you
On Mon, Aug 19, 2013 at 4:49 PM, Mark Thomas <ma...@apache.org> wrote: > 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 > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
