Hi, On Thu, Jul 26, 2018 at 2:57 AM, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Huxing, > > On 7/25/18 11:28 AM, Huxing Zhang wrote: >> Hi, >> >> Recently I am working on implementing a feature that can >> automatically register a ServletContextListerner instance, say A, >> to servletContext programmatically during startup. >> >> I use ServletContainerInitializer and call the >> servletContext.addListener() method. This is fine for most of the >> cases. But if user has specified A in web.xml, it turns that A will >> be registered twice, which will lead to undesired behavior. >> >> My expected behavior will be registering A only once regardless of >> user specified A in web.xml or not. >> >> I can achieve this by specifying A in web-fragment.xml, since it >> will get merged into web.xml whenever A is defined in web.xml or >> not, which means duplicates can be removed. >> >> I am wondering why we can not achieve this using programatic API. >> >> I've checked servlet 4.0/3.1 spec, in 4.4.3.1 "void >> addListener(String className)", it says: >> >> If the class with the given name implements a listener interface >> whose invocation order corresponds to the declaration order, that >> is, if it implements javax.servlet.ServletRequestListener, >> javax.servlet.ServletContextListener or >> javax.servlet.http.HttpSessionListener, then the new listener will >> be added to the end of the ordered list of listeners of that >> interface. >> >> It looks tomcat's behavior is spec-compliant. >> >> My idea is if I can get all the existing listeners from >> servletContext, then I can decide whether to add A or not. >> >> But I can't find that kind of API from servletContext. >> >> I also noticed that there are getServletRegistrations() and >> getFilterRegistrations() in servletContext, why can't we have API >> like getListeners()? > > Can you think of a use-case where addListener() shouldn't > automatically perform de-duplication?
No, I can't think of that case. 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. Overall, I don't think it is necessary to have unless there is a case. > 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. > > 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. :) Maybe we can improve spec as well. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltYyDIACgkQHPApP6U8 > pFhSmA//We21JrL+KwpbPrNgicIM0T77/WFMQyNoaFrW0+QdJ96CUAWYr6NKn17t > 0Y0mk9WpRDSIsknpXPTYfisO1RllO7Mde1KuGH6EUMZyYWr84E9YhqBVyOHG48if > Y/COneCHK3Gs7QlywgRhyKDZFogDFS/X5zW+AGctFIdcdgBu0z8U85a/wlPLUTuk > XA00qPLrIWSXerB97nsqcdreh7Qs2Uyx3Eye74JE4RwzRYkGVYrMuPpPQwudbAUF > f2fgAHC5lrJBGLK4yiFce53KcwTzeyBM2yskux/1y02NUyHIASpjV8DqADthV61o > SOFgG25PJChShsLQipjhcNQtqiluP4FNo1sN78ieMABfOm1zlIh4T4/4M8VD0MqP > qdoXgqC8vEsCiGUY7rqQKIRTAe6Hpf2yz6Oygwhfk+6z2CpJ4RQfsAFMVJMf2KOM > wjb6akXnrEzxPG6UEVxtep2cLLVraHlbjDHzNqMrecBC2EYHU/Ovh+gpsHXtJG8v > +Koh9HR2Ps5h92PI5ND39JsD1KyNhO+zayYD/a+I9ryrQEKV584JyU6q3vyWIwXk > m8eDlYo0ChCeiGwQ22bAOsdKYTJHruGPEg92VbbDipPLJ+8uzAbtEAlXmiGYkv2B > Q3EtprVkD1sI88v/iRU8QZg7ux5ebKDHGIk1f33BP3AYUWnwcyY= > =jKMW > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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
