On 26/07/2018 04:29, Huxing Zhang wrote:
Hi,
On Thu, Jul 26, 2018 at 2:57 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
<sniup/>
Can you think of a use-case where addListener() shouldn't
automatically perform de-duplication?
No, I can't think of that case.
Yes, although only for the programmatic case.
Multiple instances of the same listener configured differently. E.g. I
can see a use for a simple
javax.servlet.http.HttpSessionAttributeListener that might be added
multiple times in a single app to define different actions for different
attributes. Yes it could be implemented as a single listener but I can
certainly see some scenarios where adding the same listener multiple
times would give cleaner / simpler code.
If there is really a case, I think we can use
javax.servlet.ServletContext#setInitParameter to control that
behavior.
For example, use a initialization parameter named
DEDUPLICATE_LISTENERS, if set to true, any further registration will
be de-duplicated.
This parameter is better to be a per call parameter rather than a
global parameter, because it might be updated from multiple place.
Configuration at that point may cause problems. I'm not sure that the
ServletContext would be available early enough. It would be better as an
attribute on the Context. That would also be consistent with other such
configuration parameters.
I'm thinking that Tomcat should
simply take a call to addListener() and ignore any registrations after
the first one. >
Yes, I think it is important to have consistent behavior between
web-fragement/@WebListener and programmatic API.
-1. That behaviour is not consistent with the Servlet spec. The spec
expects multiple instances. It isn't explicit but it is very strongly
implied both by the wording used and the complete absence of any
indication of how de-duplication should be performed.
Further, de-duplication is not that simple. Some users will want the
fist listener added. Some the most recent. There are probably other
complications I haven't thought of.
Would that make sense? Would it violate any spec-defined behavior?
I can't find any spec describing how to handle the duplications on
that part, so I guess it is safe to do so. :)
There are lots of behaviours the spec doesn't define. That doesn't mean
implementing them is spec compliant. Exactly the opposite in fact.
Maybe we can improve spec as well.
Hopefully, with the move to Eclipse, the various clarifications that
have been open for a number of years will now start to be addressed. I'd
recommend adding this to them
https://github.com/eclipse-ee4j/servlet-api/issues
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
