tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <>
Subject Re: [next] What's next ?
Date Mon, 06 Oct 2003 23:34:34 GMT wrote:
> Glenn Nielsen wrote:
>>Remy Maucherat wrote:
>>>Glenn Nielsen wrote:
>>>>I proposed a while ago to implement a custom java policy for the
>>>>SecurityManager which uses XML for configuring permissions for
>>>>the Java SecurityManager.  There were a number of features which
>>>>made configuring a strict security policy easier.  You can look
>>>>back through the archives for the initial proposal and discussion.
>>>It's an open discussion :)
>>>However, I'd say this is an uphill battle. I think Costin argued the
>>>same earlier, and the "standard" policy file remained consistent, and
>>>now added JMX security rather (which is an important feature since we're
>>>now JMX based). So well, I don't know ...
>> From what I recall of the discussion, the issue was not with adding
>>this as a feature, but with how it was implemented using Castor.
> Castor was clearly a big problem, but not the only one :-)
> My big concern was about inventing yet-another application-specific DTD.
> If you want to support an XML format that is in use by 1-2 other
> applications - great. If you can discuss this issue with any other project
> and come to an agreement - again, I'm ok. But if this is an XML that only
> tomcat uses - I would rather stick with the standard policy format.

Point me at these other projects which are using an alternate policy file
and I will gladly cooperate with them to come up with a standard DTD or
XML Schema.  But I don't think collaboration should be a prerequesite to
add a new feature.  Tomcat could be the leader in defining the format.

> IMO parsing and generating a policy file is a bit more difficult than
> parsing/generating XML - but not by much, and it's just some code.
> Documenting and supporting an XML DTD - and getting people to understand
> and use it is far more difficult. Almost anyone how uses security policies 
> knows the standard format. To force a new syntax on the user just because
> XML is a bit easier to parse is not a good idea IMO.

When originally proposed it was implemented as a pluggable alternative,
those who wanted to use the standard policy file could still do so.
Though pluggable it did require that code be added to Tomcat to support
the new features.

>>For those who have to maintain strict java security policies the current
>>policy file format of granting permissions is a pain to use.  The XML
>>based policy feature I designed is much easier to use.
> I disagree - if you mean that XML makes it somehow easier to use because of
> the <>. It is usually easier to use what you know or can learn from others.
> If you mean the extra flexibility you proposed - like ability to define a
> policy file per app, etc - I agree, but that's unrelated with XML.

The new security policy flexibility and ease of configuration could not
be done with the current policy file format.  XML seemed like the best
choice for the format of a new policy file so that the new policy
configuration features could be added.

> Costin



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message