I just pushed the code upstream. I'll close the issues I created for tracking the basic requirements for the module. We can then create new ones for everything we want to implement on top of that.
2013/6/11 John D. Ament <john.d.am...@gmail.com> > +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 > > > > > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
