+1 as well, looks good to me.
On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg <strub...@yahoo.de> wrote: > +1 let's move forward! > > Otherwise we will spend way too much time with discussions and too less > with productive hacking ;) > > LieGrue, > strub > > > > > ----- Original Message ----- > > From: Christian Kaltepoth <christ...@kaltepoth.de> > > To: dev@deltaspike.apache.org > > Cc: > > Sent: Tuesday, 11 June 2013, 17:29 > > Subject: Re: Servlet module prototype > > > > Hey all, > > > > I finished the modifications I proposed in my last mail. The code is now > > split up into different filters and listeners for each job. I think this > > makes the code much cleaner an maintainable. You can have a look at the > > branch here: > > > > https://github.com/chkal/deltaspike/tree/servlet > > > > Especially this package: > > > > > https://github.com/chkal/deltaspike/tree/servlet/deltaspike/modules/servlet/impl/src/main/java/org/apache/deltaspike/servlet/impl > > > > For now I registered all the listeners in web-fragment.xml: > > > > > https://github.com/chkal/deltaspike/blob/servlet/deltaspike/modules/servlet/impl/src/main/resources/META-INF/web-fragment.xml > > > > If you all agree, I could rebase and merge the current state into the > > Apache repository. > > > > After I merged it, we could discuss how to implement ways to disable > parts > > of the functionality. Either by implementing a dynamic registration using > > ServletInitializers or by using Deactivatable. > > > > What do you think? > > > > Christian > > > > > > > > 2013/6/8 Christian Kaltepoth <christ...@kaltepoth.de> > > > >> Hey John, > >> > >> thank you very much for sharing your thoughts on this. It is very > >> interesting for me to hear about the feedback your got from Solder > users. > >> And I think we should definitely address the issues you pointed out. > >> > >> So my idea would be the following. I could start separating the filter > and > >> the listeners into distinct classes with explicit functions. For > example > >> one filter for managing everything that is required for the injection > of > >> servlet objects and one filter for sending the events. > >> > >> After I'm done with this and if everybody agrees on the new structure, > > I > >> could merge the current state into the main repository. After that we > could > >> think about and work on an approach to partially disable functionality > >> which should be easy to implement with this new structure. > >> > >> What do you think? > >> > >> > >> > >> > >> 2013/6/7 John D. Ament <john.d.am...@gmail.com> > >> > >> Hi Christian, > >>> > >>> Actually I was going to respond this morning but got side tracked. > >>> > >>> Anyways, I agree that the servlet module needs to provide all of this > >>> functionality, however I think we need to make sure that it's more > >>> scalable > >>> than the way this worked in solder/seam3. The biggest gripe I hear > > from > >>> people about seam3 was that it was all or nothing. It was difficult > to > >>> activate only portions of the functionality. I think we started to do > >>> that > >>> in DS with the deactivateable function but there are certain places > > where > >>> it makes sense to deactivate in other ways. > >>> > >>> What I'm suggesting is that we: > >>> > >>> 1. Separate the listeners out - can we have two listeners, one for the > >>> context listener and one for the session listener. > >>> 2. Come up with some way that the filters can be more manageable. For > >>> example, maybe I'm only interested in request, not response. Maybe > > I only > >>> want Initialized and not Destroyed. This way we don't have to fire > > the > >>> event every single request. This is probably a good case for > >>> deactivatable, but more at the class feature level. > >>> 3. Come up with a way to make this not automatically installed, even > if > >>> you > >>> include the servlet module in your archive. if metadata complete is > > the > >>> best option, we should just document the use of metadata complete to > >>> disable the installation. > >>> > >>> John > >>> > >>> > >>> On Fri, Jun 7, 2013 at 11:23 AM, Christian Kaltepoth < > >>> christ...@kaltepoth.de > >>> > wrote: > >>> > >>> > Sorry, I think my mail wasn't very clear. Sorry for the > > confusion. :) > >>> > > >>> > The servlet module provides two features: the injection of servlet > >>> objects > >>> > and the propagation of servlet events. It makes sense that the > > request > >>> > events can be disabled. But IMHO the producers that allow > > injection of > >>> > servlet objects is a fundamental feature of the servlet module > > without > >>> any > >>> > performance overhead and should therefore not be deactivateable. > >>> > > >>> > The filter implemented in the servlet modules does two things: > >>> > > >>> > - It stores the request and the response in a ThreadLocal. The > >>> producer > >>> > methods use this ThreadLocal to access the request/response. So > > the > >>> > request/response injection requires this filter to work > > correctly. > >>> > - The filter also propagates the servlet events to the CDI > > event bus. > >>> > This is something that should be deactivatable. > >>> > > >>> > The same applies to things like the ServletContextListener. This > > one > >>> stores > >>> > the ServletContext in a map for each context class loader and it > > sends > >>> the > >>> > events for it's construction and destruction to the event bus, > > while > >>> only > >>> > the latter one should be deactivateable. > >>> > > >>> > What I wanted to say in my previous mail is that we cannot use a > >>> > ServletContainerInitializer > >>> > which register the filter only if the servlet events are not > > disabled, > >>> > because this would not only disable the servlet events but also > > break > >>> the > >>> > injection of the request/response into CDI beans. > >>> > > >>> > So I think it would make sense to always register the filter using > >>> > web-fragment.xml. Additionally we could control if the events are > > fired > >>> or > >>> > not using the config resolver approach that you talked about. But > > the > >>> > ThreadLocal management should always be active so that the > > injection of > >>> > request/response works like expected. > >>> > > >>> > To sum it up: IMHO we will _always_ need the filters and the > > listeners > >>> in > >>> > the servlet module, but we should allow to disable certain parts > > of > >>> their > >>> > functionality. > >>> > > >>> > I hope this makes everything a bit clearer. :) > >>> > > >>> > Christian > >>> > > >>> > > >>> > > >>> > > >>> > 2013/6/7 Romain Manni-Bucau <rmannibu...@gmail.com> > >>> > > >>> > > If a user deactivate it it means it doesn't it the > > feature so no need > >>> of > >>> > > any thread local. If a module needs it it can just override > > the > >>> > > configuration to force it (through config resolver) so i > > still think > >>> my > >>> > > proposal was possible and better than having it always on (if > > i missed > >>> > sthg > >>> > > just push a bit more your explanations please). > >>> > > > >>> > > *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> > >>> > > > >>> > > > @Romain: > >>> > > > > >>> > > > The filter and the listeners do not only send the events > > but also > >>> > manage > >>> > > > the ThreadLocals required for the producers. So > > currently it is > >>> > required > >>> > > to > >>> > > > have the filter and the listeners configured for the > > injection to > >>> work. > >>> > > > That's why I think that it makes sense to always > > have the filter and > >>> > > > listeners in place and just don't send the events if > > the user > >>> disabled > >>> > > > them. And of cause one could use ConfigResolver for > > that. > >>> > > > > >>> > > > @Mark: > >>> > > > > >>> > > > So you say that firing events is expensive even if there > > are no > >>> > observers > >>> > > > listening? > >>> > > > > >>> > > > Generally I like the idea of having DeltaSpike > > automatically detect > >>> > that > >>> > > > certain features can be disabled because they are not > > used. So if > >>> > nobody > >>> > > > listens for servlet events, the filter could simply > > never send them. > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > 2013/6/7 Gerhard Petracek > > <gerhard.petra...@gmail.com> > >>> > > > > >>> > > > > the general jira-issue for it is [1]. > >>> > > > > > >>> > > > > regards, > >>> > > > > gerhard > >>> > > > > > >>> > > > > [1] > > https://issues.apache.org/jira/browse/DELTASPIKE-349 > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > 2013/6/7 Mark Struberg <strub...@yahoo.de> > >>> > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > Gerhard and me thought about this for quite a > > few other > >>> features as > >>> > > > well. > >>> > > > > > > >>> > > > > > > >>> > > > > > Event firing is indeed a bit expensive. Thus > > we might add a > >>> > > > > > > >>> > > > > > > >>> > > > > > Map<Class<? extends Deactivatable> > > /*the 'feature'*/, > >>> Set<Class<?>> > >>> > > > > > /*types which get observed*/ > >>> > > > > > > >>> > > > > > and utilize @Observes ProcessObserverMethod to > > check whether > >>> there > >>> > > is a > >>> > > > > > need to activate this feature at all. > >>> > > > > > > >>> > > > > > In short: if there is no ObserverMethod which > > @Observes ? > >>> extends > >>> > > > > > ServletResponse or ServletResponse then we > > don't need to fire > >>> any > >>> > CDI > >>> > > > > > event. Not sure if this is needed though or > > whether the > >>> Containers > >>> > > are > >>> > > > > > smart enough to optimize this away themselfs > > (with a negative > >>> cache > >>> > > > kind > >>> > > > > of > >>> > > > > > thingy). > >>> > > > > > > >>> > > > > > > >>> > > > > > LieGrue, > >>> > > > > > strub > >>> > > > > > > >>> > > > > > >________________________________ > >>> > > > > > > From: Christian Kaltepoth > > <christ...@kaltepoth.de> > >>> > > > > > >To: dev@deltaspike.apache.org > >>> > > > > > >Cc: Mark Struberg > > <strub...@yahoo.de> > >>> > > > > > >Sent: Friday, 7 June 2013, 8:22 > >>> > > > > > >Subject: Re: Servlet module prototype > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > >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 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 > >> > >> > > > > > > -- > > Christian Kaltepoth > > Blog: http://blog.kaltepoth.de/ > > Twitter: http://twitter.com/chkal > > GitHub: https://github.com/chkal > > >
