Ok let me rephrase. I basically agree on the perf issue (i typically have case where i want to use cdi to observe webapp lifecycle but not request/session) so i want to disable some part too if my deps doesn't need it. But using a container initializer as mentionned before you can use ConfigResolver to only register what is not disabled (all by default). That's easy and don't need any xml (so you don't ask the user to know a lot of thing about internals and it is compliant with our current configuration).
Looking our conf it seems to start to be designed as a tree (globalAlternative prefix makes me think to it) so we'd need a web prefix probably. *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> > 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 >
