On 15/09/2012 00:15, Ron Monzillo wrote:
> On 9/14/12 6:02 PM, Mark Thomas wrote:
>> I don't see the proposal as making things easier for anyone - container developers or application developers. I have read your proposal several times and I am still not sure I fully understand it. Hence, I am far from convinced that developers will understand what the option does, let alone use it.
>>
>> If it wasn't for annotations, mis-configured applications could be fixed by simply deleting the <http-method> elements in web.xml. Annotations complicate things rather in this case. There are ways around this but they aren't as simple.
> leaving annoations out of it, there are cases where a developer will
> want to enumerate http methods, and the
> configuration will no longer be correct if we simply remove them.
Thanks for the example. That really helps to clarify things. My
simplistic approach isn't going to work.
There have been three approaches proposed to address this issue:
a) Better documentation
I don't see any issue with the detail of the current example in the
Servlet spec but I'm sure the supporting text could be extended to more
clearly articulate the potential pitfalls you are concerned about. If
you open a Jira and add some suggested edits then I think there is a
good chance your suggestions will be accepted.
b) Logging uncovered methods
This could be mandated by the specification, suggested by the
specification or independently implemented by containers. I do have a
small concern in that a valid configuration may have an uncovered method
so mandating that this is logged would cause issues in environments that
require all logged warnings are resolved. It would, therefore, have to
be possible to suppress any such log message.
c) Block uncovered methods
This obviously has to be optional. Again, it could be mandated by the
specificationor independently implemented by containers (as per the
original proposal).
Given that the existing features can be used securely, I don't like c)
as it adds another way to do that same thing and I inherently dislike
that. I like it even less when the current features are already quite
complex. Therefore, I think my preference is for b). I'd be quite happy
for the spec to require containers to log a warning in this case with a
container specific way to disable the logging if required.
JIRA issues are the way to progress b) and c). I think you stand a much
better chance of b) being accepted than c).
Mark