My experience with seam servlet observers is that it causes performance cost when use ajax. When there are many browser callbacks per page (including jsf resources), there is a noticeable cost.
I suggest a @IncludePath filter to be added so only specific context paths would trigger an event to be fired. Or opposed an @ExcludePath filter. On Jun 7, 2013, at 8:22 AM, Christian Kaltepoth <christ...@kaltepoth.de> wrote: > I think Nicklas and John fear that firing events for each request/response > could lead to performance issues!?! > > But I'm not sure if there will be a noticeable performance impact if there > are no observers for the events. I don't think that firing an event that > nobody observes is expensive. > > And I also think that Solder didn't provide any way to disable these events > (correct me if I'm wrong). Or has there been any reports regarding Solder's > performance? > > > 2013/6/7 Romain Manni-Bucau <rmannibu...@gmail.com> > >> Hi >> >> in fact i don't get why you would like to be able to deactivate it. >> Basically it is a web *module* so if it is here it is either needed by a >> dep or you explicitely imported it so you want it. So basically a >> configurable (through ConfigResolver) ServletContainerInitializer is just >> what we need to be able to deactivate not needed listeners. Other config >> can break modules relying on it so it could prevent lib to use this module. >> >> *Romain Manni-Bucau* >> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* >> *Blog: **http://rmannibucau.wordpress.com/*< >> http://rmannibucau.wordpress.com/> >> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* >> *Github: https://github.com/rmannibucau* >> >> >> >> 2013/6/7 Christian Kaltepoth <christ...@kaltepoth.de> >> >>> The servlet module doesn't work at all without the filter and the >>> listeners. So I think it absolutely makes sense to include them in a >>> web-fragment.xml inside the servlet-impl module. If something like >>> filter/listener ordering is an issue for users, they can still set >>> "metadata-complete" and manually add the required entries into their own >>> web.xml. Or they could use <absolute-ordering>. >>> >>> But I agree that it should be possible to disable the events (all events >> or >>> perhaps just the request/response events?). The question is which way the >>> user should use to configure this. Of cause we could also use a servlet >>> context parameter. Something like: >>> >>> <context-param> >>> <param-name>org.apache.deltaspike.DISABLE_SERVLET_EVENTS</param-name> >>> <param-value>true</param-value> >>> </context-param> >>> >>> But DeltaSpike already provides a mechanism for disabling features which >> is >>> part of the core module and is already used in various other places. If >> we >>> allow users to deactivate features, we should be consistent in how users >>> can do it. >>> >>> Is it correct that there is currently no implementation of >> ClassDeactivator >>> in DeltaSpike at all? What about adding an implementation that uses >> servlet >>> context parameters to the servlet module? Wouldn't this be a nice >>> enhancement? This way users could either use "simple" servlet context >>> parameters or they could use some other more flexible way if they want >> to. >>> >>> Christian >>> >>> >>> >>> >>> 2013/6/6 John D. Ament <john.d.am...@gmail.com> >>> >>>> What if the web-fragment.xml were in a separate JAR? >>>> Deactivatable is a custom solution, I'd love to avoid using it. >>>> >>>> >>>> On Thu, Jun 6, 2013 at 11:03 AM, Christian Kaltepoth < >>>> christ...@kaltepoth.de >>>>> wrote: >>>> >>>>> @John, @Nicklas: >>>>> >>>>> I agree that it should be possible to disable the servlet events. >> But I >>>>> think we should automatically register the filter and the listeners >>> using >>>>> web-fragment.xml because they are required for the injection to work >>>>> correctly. >>>>> >>>>> Isn't this a perfect use case for Deactivatable? We could simply >>> define a >>>>> dummy implementation of Deactivatable which can be used to disable >> just >>>> the >>>>> events. We already do something with GlobalAlternative: >>>>> >>>>> >>>>> >>>> >>> >> https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exclude/GlobalAlternative.java#L26 >>>>> >>>>> >>>>> >>>> >>> >> https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/exclude/extension/ExcludeExtension.java#L91 >>>>> >>>>> What about this: >>>>> >>>>> public interface ServletEventBridge implements Deactivatable { } >>>>> >>>>> Thoughts? >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> 2013/6/6 John D. Ament <john.d.am...@gmail.com> >>>>> >>>>>> I'd prefer if we simply didn't include the web-fragment.xml and >>> instead >>>>>> provided instructions on the wiki on how to enable them. >>>>>> >>>>>> >>>>>> On Thu, Jun 6, 2013 at 4:37 AM, Nicklas Karlsson < >> nicka...@gmail.com >>>> >>>>>> wrote: >>>>>> >>>>>>> I would also drop the @Web-annotation, I think. BTW, can the >>>>>>> request/reponse lifecycle events be disabled? I would assume that >>>> there >>>>>> is >>>>>>> a lot of firing going off for an ajax-application and they >>> observers >>>>> will >>>>>>> have to be resolved even if there are no observers(?) >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 6, 2013 at 11:25 AM, Mark Struberg < >> strub...@yahoo.de> >>>>>> wrote: >>>>>>> >>>>>>>> Nice work! >>>>>>>> >>>>>>>> The @Web Qualifier looks a bit odd, but will turn out into the >>>>> broader >>>>>>>> discussion about how to implement features which might get >>> 'added' >>>> in >>>>>>>> future specs. >>>>>>>> >>>>>>>> >>>>>>>> LieGrue, >>>>>>>> strub >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: Christian Kaltepoth <christ...@kaltepoth.de> >>>>>>>>> To: "deltaspike-...@incubator.apache.org" < >>>>>>>> deltaspike-...@incubator.apache.org> >>>>>>>>> Cc: >>>>>>>>> Sent: Thursday, 6 June 2013, 6:56 >>>>>>>>> Subject: Servlet module prototype >>>>>>>>> >>>>>>>>> Hey all, >>>>>>>>> >>>>>>>>> I spent some time working on a first version of the servlet >>>> module. >>>>>> All >>>>>>>> the >>>>>>>>> basic features are finished now and therefore I think its >> time >>> to >>>>> ask >>>>>>> for >>>>>>>>> some feedback. >>>>>>>>> >>>>>>>>> I pushed the code to the "servlet" branch on my github repo: >>>>>>>>> >>>>>>>>> https://github.com/chkal/deltaspike/tree/servlet >>>>>>>>> >>>>>>>>> The servlet module provides two major features: >>>>>>>>> >>>>>>>>> * Injection of servlet various objects >>>>>>>>> * Servlet lifecycle events >>>>>>>>> >>>>>>>>> The producers are using the qualifier @Web to avoid conflicts >>>> with >>>>>> CDI >>>>>>>> 1.1. >>>>>>>>> We could discuss whether some other name for the qualifier >> fits >>>>>> better. >>>>>>>>> >>>>>>>>> See the following classes from the tests to get an idea of >> what >>>> can >>>>>> be >>>>>>>>> injected: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/producer/ServletObjectInjectionBean.java >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/producer/ServletContextInjectionTest.java >>>>>>>>> >>>>>>>>> The lifecycle events are fired using the qualifiers >>> @Initialized >>>> or >>>>>>>>> @Destroyed just like in Seam Solder. I also added the @Web >>>>> qualifier >>>>>> to >>>>>>>> all >>>>>>>>> events, but we could discuss whether this is really >> necessary. >>>>>>>>> >>>>>>>>> The following classes show which events can be observed: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/request/RequestResponseEventsObserver.java >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/session/SessionEventsObserver.java >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/test/java/org/apache/deltaspike/test/servlet/impl/event/context/ServletContextEventsObserver.java >>>>>>>>> >>>>>>>>> One thing that I'm not quite happy with is the way the >>>>> ServletContext >>>>>>>>> injection works. I'm currently using a map that stores the >>>>>>> ServletContext >>>>>>>>> for each context class loader. IMHO this is better than using >>>>>>>>> HttpServletRequest.getServletContext() as it also works for >>>> threads >>>>>>>> outside >>>>>>>>> of a request (like schedulers for example). I also wanted to >>>> avoid >>>>>>> using >>>>>>>>> the CDI application scope for storing the ServletContext to >>> avoid >>>>>>>> problems >>>>>>>>> regarding different implementations of the scope in regard to >>> EAR >>>>>>>>> packaging. I would be very interested in hearing your >> thoughts >>> on >>>>>> this. >>>>>>>> :) >>>>>>>>> >>>>>>>>> One other thing. As I currently don't use any Servlet 3.0 >>>> features, >>>>>> the >>>>>>>>> module depends on the Servlet 2.5 API. Do you think it makes >>>> sense >>>>> to >>>>>>>> still >>>>>>>>> support Servlet 2.5 or should we require at least Servlet >> 3.0? >>>>>>>>> >>>>>>>>> Looking forward to your feedback. Especially I would like to >>> know >>>>> if >>>>>>> you >>>>>>>>> think that the code should be merged into the upstream >>>> repository. >>>>> :) >>>>>>>>> >>>>>>>>> Christian >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Christian Kaltepoth >>>>>>>>> Blog: http://blog.kaltepoth.de/ >>>>>>>>> Twitter: http://twitter.com/chkal >>>>>>>>> GitHub: https://github.com/chkal >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nicklas Karlsson, +358 40 5062266 >>>>>>> Vaakunatie 10 as 7, 20780 Kaarina >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Christian Kaltepoth >>>>> Blog: http://blog.kaltepoth.de/ >>>>> Twitter: http://twitter.com/chkal >>>>> GitHub: https://github.com/chkal >>>>> >>>> >>> >>> >>> >>> -- >>> Christian Kaltepoth >>> Blog: http://blog.kaltepoth.de/ >>> Twitter: http://twitter.com/chkal >>> GitHub: https://github.com/chkal >>> >> > > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal
