On July 26, 2018 6:08:09 PM UTC, Christopher Schultz <ch...@christopherschultz.net> wrote: >-----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
Probably easier to have the listener handle multiple registrations itself for that use case. I.e. given that listeners are started serially in a single thread, check/set a servlet context attribute when the listener starts. That should work for any container without having to depend on container specific behaviour. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
