Thank you Ron for your response.
Allow me to clarify further. And please if this is still not enough, just
ask.
The JSP RI (which is the forked Jasper implementation) contains the
following:
public static final boolean IS_SECURITY_ENABLED =
(System.getSecurityManager() != null);
While this seems to be innocuous enough what it really means is that no
consumer of that impl can rely on the SecurityManager API.
My first reaction was to file a bug report:
https://java.net/jira/browse/JSP-37
I also went to the original developers, the tomcat project developer list,
and asked for their position on the matter. The discussion was quickly
curtailed as "we don't support dynamic changes of the SecurityManager".
Understandable, since at this point tomcat's Jasper is a "custom
implementation" of the JSP spec.
Therefore, I had hoped that at the Java EE specification level someone may
at least be inclined to offer a statement toward whether there is even
grounds for making such a bug report.
So my goal here is simply to identify whether there is some precedent,
charter of behaviour, set of rules, code of conduct, etc., by which the
Java EE specifications and their RIs are obliged to NOT break the
behaviours of the Java SE APIs upon which they are founded, even while not
containing or omitting specifics in their language or wording.
It seems to me that the RIs developed within Java EE should not take
liberties that custom implementations may afford to take since RIs tend to
be, by their nature, more portable and representative of best practices.
I hope that clarifies things.
Sincerely,
- Ray
On Wed, Aug 21, 2013 at 12:45 PM, Ron Monzillo <ron.monzillo_at_oracle.com>wrote:
> On 8/21/13 11:31 AM, Raymond Auge wrote:
>
> Hello everyone,
>
> My name is Raymond Auge and this is my first email to the list.
> Hopefully I follow proper protocol. Please let me know if I have not.
>
> -----
> Sorry, my question may seem odd.
>
> I would like to get an official position statement on the handling of
> the SecurityManager/Policy APIs with respect to Java EE?
>
> I suppose I am asking:
>
> "Is it OK for Java EE specifications/implementations to make assumptions
> about the state of the SecurityManager/Policy without respecting changes in
> their runtime state?"
>
> If you think there is an issue with the specifications, it would help if
> you could provide a reference to the
> specification content.
>
> that said, a perhaps overly simplistic answer to your question, is that EE
> 7 requires that every EE product be able to run with a security manager
> enabled. So for example, it would not be appropriate for an implementation
> to assume that a security manager will not (or at least never) be enabled.
> For prior releases of EE, one might conclude otherwise.
>
> Regarding the runtime or installation specific state of access control
> Policy (as enforced by the Policy system) there is an expectation that the
> Policy implementation enforce the policy as configured for the
> installation, with the additional requirement that every EE product provide
> a means for applications to be granted some specific permissions identified
> in the EE specification.
>
> EE 7 also added a new facility by which applications may declare the
> permissions that they require.
>
> I'll stop there for now,
>
> Ron
>
> --
>
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
>
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect
*Liferay, Inc.* <http://www.liferay.com> (@Liferay)