+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 >
