On 01/03/17 21:38, Edward Burns wrote:
>>>>>> On Fri, 17 Feb 2017 22:02:13 +0000, Mark Thomas <markt_at_apache.org> said:
>
> MT> The only difference I have found is that Tomcat's implementation has an
> MT> an explicit MappingMatch.UNKNOWN whereas the spec version doesn't.
>
> MT> I think there is merit is using an explicit value for UNKNOWN. I think
> MT> it makes the code using it easier to read.
>
> I have merged the feature from the SERVLET_SPEC-73 branch to the API
> trunk.
Great. I've done a quick diff to Tomcat's implementation with javap and
all looks good.
> Mark, I removed MappingMatch.UNKNOWN because I was unable to
> come up with a satisfactory answer to the following question: Under what
> circumstances will MappingMatch.UNKNOWN be returned as the value of
> getMappingMatch()?
>
> Now, if you feel that having MappingMatch.UNKNOWN for the sole purpose
> of returning it from the default implementation is sufficient reason, we
> can consider it, but I'd like to know why you think it's necessary.
I wouldn't say it is necessary but I would say it is beneficial. My
primary reason is because it results in cleaner code:
switch(mappingType) {
case...
}
rather than
if (mappingType == null) {
...
} else {
switch(mappingType) {
case...
}
}
There are some edge cases that can result in null (or as I would prefer
MappingMatch.UNKNOWN). The default implementation is one. The other is a
request that results in a 404 when no default servlet is present.
I can't see any other edge cases after a quick look at Tomcat's
implementation but I guess it is possible there may be other edge cases
in other implementations.
Mark