-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 7/26/18 5:21 AM, Mark Thomas wrote: > 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 FWIW, I was not suggesting that all types of listeners be deduplicated. I was instead focusing on ServletContextListeners, since that was Huxing's use-case. I should have been more clear in my proposal . On the other hand, listeners cannot be registered with any information other than their class. Therefore I'm not sure that adding the same class multiple times to the event-notification list would accomplish anything useful. Hmm... I just realized that the programmatic interface allows listeners to be added by /instance/ and not just by class (name), so theoretically one could instantiate two instances of a single class, each with different behaviors (configured via constructors or other mutators) and they would therefore be "distinct". Rather than deduplicating by class, perhaps we could deduplicate by using .equals(). In that case, if you had something like this: class MyListener extends HttpSessionAttributeListener { MyListener(String attributeName) { ... } } Then registering one instance of this class with attribute name "foo" versus "bar" could work as long as MyListener can prove that the two instances are distinct (e.g. by comparing their "attribute names"). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltaDggACgkQHPApP6U8 pFhg2w//ZuhPBU6LzWYJksEKh/HcPLaXZODjqCUA8xl8EBEXyIbqu6Bafl2QlKxT J2yprTHefOKAI7TOY8yPWtdiwCFCgI1yMOD6HDp4J5MhWziKV+0bbOjrrG1Vuia1 i1Sspvue3XyWVcpMF40/LGRC6BDlNcN+XqCfwfODXD5JLKxpaFZIKSLNDb2cttEH 7rJhQHwqxqGj5OUxlA5y/TRBzTKihH789PG0XKukXeYLzW64KhzB9kVIYJTgVmT4 rWOMUmMRBB2VVi4ovmmRy/O4Y8t0VXZvdQVb9EwVKlSKvnoO6tVLgsVGAKG966EB SdTEBeUIkwPdYYbv2lL7OgpHAOUAmwBtwZhs8UFUCIU1nCi2FUS8kqbMNIlDk431 J8Ad9PQ3jh/A01m3XScKL+/4qVx550lxQEk1Zd7wsajgtbJPZo0ZOA+Iy1x5huDx IbudWubPMJudxJLvjb8kb2aDYamvMtmQF7Xb3R1aWOGezCHuB39f05Nurz8c4ZKt YrrZHjeqcYnPgpdvWBaobXZt0q3y8cbQnoovdpLiHg5l7Lb4NY9LS87KAamj+T4q ZwJVHjE7ULlLRlgdAnDu0Z0CZBdMW/Xe0ZmnE+hW6jSmsB/vDdePZTLk/g/1iddr vR2MKJ56L9xMgbYWPl144XkZN7p8GDuzHWrqZQt/FLwyCXos5L4= =Ygg3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
