Mark Thomas wrote on 02/06/2013 01:59 AM:
> On 06/02/2013 04:28, Bill Shannon wrote:
>> Hi Greg. I'm not aware of all the background here but my understanding
>> is that the Servlet expert group has seen this proposal of yours before.
>> Your proposal is a different matching algorithm to determine which
>> security constraints apply to which http requests. I understand that
>> you believe it is more intuitive, but I'm not seeing any support for
>> this different model from other members of the Servlet expert group.
>
> I'm not seeing any EG members against Greg's proposal either. I am not
> seeing any support for your proposal and a number of EG members are
> against it. On that basis, Greg's proposal has more support than yours.
Maybe I'm not seeing all the email, but I've only seen messages from you
and Greg objecting to my message. And just recently Jeff's message in
support of it, along with the support from the platform expert group.
>> In any event, it's getting pretty late in this release to consider
>> such a significant change. As Ron has described, our proposed change
>> does not change the matching algorithm at all, and so is a somewhat
>> simpler change to introduce at this late date.
>
> I have already articulated my reasons why I am against this proposal and
> have suggested alternative approaches that still solve the problem
> without introducing complexity.
Logging is not a solution.
>> Given that the platform expert group widely support our proposed change,
>> and that there's no support even in the Servlet expert group for your
>> change, I think we need to go ahead with our change as proposed.
>
> Give that every comment from Servlet EG members on your proposal has
> been against this change I would hope that it was not forced through
> against the advice of the folks that are, after all, meant to be the
> subject matter experts.
>
> What I find particularly offensive is that after some discussion of the
> proposal and suggestions from the Servlet EG, rather than spending the
> last three months working with the Servlet EG to reach a consensus you
> went to the platform EG and are attempting to force the change on the
> Servlet EG almost at the end of the process.
If you talk to most of the JCP EC members, they'll tell you that they'd
like to see some sort of "architecture council" that could address issues
such as this. We've resisted creating such a thing because we believe that's
exactly the role of the platform expert group.
The only conclusion the Servlet expert group could come up with was
"don't solve the problem". We didn't believe that was acceptable, and
the platform expert group agreed with us.
>> If you still think a more significant change is desirable, feel free to
>> bring it up again for Java EE 8.
>
> I agree with Greg that a simpler model is desirable but the backwards
> compatibility requirement is always going cause complications.
>
> Adding more, unnecessary complexity now is a mistake. It will only
> create a bigger mess to fix later. Adding logging now, along with the
> changes proposed for the JSP specification, addresses the immediate
> issues and gives the EG time to consider better long term solutions.
> When considering long term solutions, the option to break backwards
> compatibility should be on the table as it may enable significant
> benefits in terms of simplicity.
There will be opportunities to consider other solutions in the future,
including solutions that break backwards compatibility. In the mean
time, this solution will be in place.
You may be aware that one of the things we've considered for the future
is a better and simpler structure for our deployment descriptors. We're
also considering some sort of "configuration API" that might help here.
If a consensus emerges for a better way to express web application
security, we'll have opportunities to consider that.