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.
> 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.
> 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 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.
Mark