On Fri, Jul 27, 2018 at 3:02 AM, Mark Thomas <ma...@apache.org> wrote: > 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. What if the listener isn't in control, e.g. the listener class is in a 3rd party library. In some cases, a listener may not allow multiple instances, if the second listener start, it will fail. Is it possible to add a new method in ServletContext called getListeners(), and let the user to decide whether to add it or not? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > -- Best Regards！ Huxing --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
