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

Reply via email to