You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Christian Kaltepoth <ch...@kaltepoth.de> on 2013/06/06 06:56:14 UTC
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
Re: Servlet module prototype
Posted by Ove Ranheim <or...@gmail.com>.
My experience with seam servlet observers is that it causes performance cost when use ajax. When there are many browser callbacks per page (including jsf resources), there is a noticeable cost.
I suggest a @IncludePath filter to be added so only specific context paths would trigger an event to be fired. Or opposed an @ExcludePath filter.
On Jun 7, 2013, at 8:22 AM, Christian Kaltepoth <ch...@kaltepoth.de> wrote:
> I think Nicklas and John fear that firing events for each request/response
> could lead to performance issues!?!
>
> But I'm not sure if there will be a noticeable performance impact if there
> are no observers for the events. I don't think that firing an event that
> nobody observes is expensive.
>
> And I also think that Solder didn't provide any way to disable these events
> (correct me if I'm wrong). Or has there been any reports regarding Solder's
> performance?
>
>
> 2013/6/7 Romain Manni-Bucau <rm...@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 <ch...@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 <jo...@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 <
>>>> christian@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 <jo...@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 <
>> nickarls@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 <
>> struberg@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 <ch...@kaltepoth.de>
>>>>>>>>> To: "deltaspike-dev@incubator.apache.org" <
>>>>>>>> deltaspike-dev@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
Re: Servlet module prototype
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ch...@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 <rm...@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 <ch...@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 <jo...@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 <
> > > > christian@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 <jo...@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 <
> > nickarls@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 <
> > struberg@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 <ch...@kaltepoth.de>
> > > > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > > > > > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Mark Struberg <st...@yahoo.de>.
cool, txs!
Will review those 2 new modules (bv + servlet) later today.
LieGrue,
strub
----- Original Message -----
> From: Christian Kaltepoth <ch...@kaltepoth.de>
> To: dev@deltaspike.apache.org
> Cc:
> Sent: Thursday, 13 June 2013, 7:09
> Subject: Re: Servlet module prototype
>
> 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 <jo...@gmail.com>
>
>> +1 as well, looks good to me.
>>
>>
>> On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg <st...@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 <ch...@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 <ch...@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 <jo...@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
> <
>> > >>> christian@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
> <rm...@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
> <ch...@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
>> > > <ge...@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
> <st...@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
>> > > <ch...@kaltepoth.de>
>> > >>> > > > > > >To:
> dev@deltaspike.apache.org
>> > >>> > > > > > >Cc: Mark Struberg
>> > > <st...@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
>> > > <rm...@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
>> > > <ch...@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
>> > > <jo...@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 <
>> > >>> > > > > > >>> >
> christian@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
>> > > <jo...@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 <
>> > >>> > > > > > nickarls@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 <
>> > >>> > > > > > struberg@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 <
>> > >>> christian@kaltepoth.de>
>> > >>> > > > > > >>> > > >
>> > > To:
>> > > "deltaspike-dev@incubator.apache.org" <
>> > >>> > > > > > >>> > > >
>> >
>> > > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
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 <jo...@gmail.com>
> +1 as well, looks good to me.
>
>
> On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg <st...@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 <ch...@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 <ch...@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 <jo...@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 <
> > >>> christian@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 <rm...@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 <ch...@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
> > > <ge...@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 <st...@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
> > > <ch...@kaltepoth.de>
> > >>> > > > > > >To: dev@deltaspike.apache.org
> > >>> > > > > > >Cc: Mark Struberg
> > > <st...@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
> > > <rm...@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
> > > <ch...@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
> > > <jo...@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 <
> > >>> > > > > > >>> > christian@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
> > > <jo...@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 <
> > >>> > > > > > nickarls@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 <
> > >>> > > > > > struberg@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 <
> > >>> christian@kaltepoth.de>
> > >>> > > > > > >>> > > > > > > To:
> > > "deltaspike-dev@incubator.apache.org" <
> > >>> > > > > > >>> > > > > >
> > > deltaspike-dev@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
Re: Servlet module prototype
Posted by "John D. Ament" <jo...@gmail.com>.
+1 as well, looks good to me.
On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg <st...@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 <ch...@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 <ch...@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 <jo...@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 <
> >>> christian@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 <rm...@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 <ch...@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
> > <ge...@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 <st...@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
> > <ch...@kaltepoth.de>
> >>> > > > > > >To: dev@deltaspike.apache.org
> >>> > > > > > >Cc: Mark Struberg
> > <st...@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
> > <rm...@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
> > <ch...@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
> > <jo...@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 <
> >>> > > > > > >>> > christian@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
> > <jo...@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 <
> >>> > > > > > nickarls@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 <
> >>> > > > > > struberg@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 <
> >>> christian@kaltepoth.de>
> >>> > > > > > >>> > > > > > > To:
> > "deltaspike-dev@incubator.apache.org" <
> >>> > > > > > >>> > > > > >
> > deltaspike-dev@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
> >
>
Re: Servlet module prototype
Posted by Mark Struberg <st...@yahoo.de>.
+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 <ch...@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 <ch...@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 <jo...@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 <
>>> christian@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 <rm...@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 <ch...@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
> <ge...@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 <st...@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
> <ch...@kaltepoth.de>
>>> > > > > > >To: dev@deltaspike.apache.org
>>> > > > > > >Cc: Mark Struberg
> <st...@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
> <rm...@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
> <ch...@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
> <jo...@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 <
>>> > > > > > >>> > christian@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
> <jo...@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 <
>>> > > > > > nickarls@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 <
>>> > > > > > struberg@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 <
>>> christian@kaltepoth.de>
>>> > > > > > >>> > > > > > > To:
> "deltaspike-dev@incubator.apache.org" <
>>> > > > > > >>> > > > > >
> deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
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 <ch...@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 <jo...@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 <
>> christian@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 <rm...@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 <ch...@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 <ge...@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 <st...@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 <ch...@kaltepoth.de>
>> > > > > > >To: dev@deltaspike.apache.org
>> > > > > > >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
>> > > > > > >>> > christian@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 <jo...@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 <
>> > > > > > nickarls@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 <
>> > > > > > struberg@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 <
>> christian@kaltepoth.de>
>> > > > > > >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
>> > > > > > >>> > > > > > deltaspike-dev@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
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@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 <jo...@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 <
> christian@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 <rm...@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 <ch...@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 <ge...@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 <st...@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 <ch...@kaltepoth.de>
> > > > > > >To: dev@deltaspike.apache.org
> > > > > > >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
> > > > > > >>> > christian@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 <jo...@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 <
> > > > > > nickarls@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 <
> > > > > > struberg@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 <
> christian@kaltepoth.de>
> > > > > > >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > > > >>> > > > > > deltaspike-dev@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
Re: Servlet module prototype
Posted by "John D. Ament" <jo...@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 <christian@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 <rm...@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 <ch...@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 <ge...@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 <st...@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 <ch...@kaltepoth.de>
> > > > > >To: dev@deltaspike.apache.org
> > > > > >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
> > > > > >>> > christian@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 <jo...@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 <
> > > > > nickarls@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 <
> > > > > struberg@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 <ch...@kaltepoth.de>
> > > > > >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > > >>> > > > > > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
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 <rm...@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 <ch...@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 <ge...@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 <st...@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 <ch...@kaltepoth.de>
> > > > >To: dev@deltaspike.apache.org
> > > > >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
> > > > >>> > christian@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 <jo...@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 <
> > > > nickarls@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 <
> > > > struberg@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 <ch...@kaltepoth.de>
> > > > >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > >>> > > > > > deltaspike-dev@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
Re: Servlet module prototype
Posted by Romain Manni-Bucau <rm...@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 <ch...@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 <ge...@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 <st...@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 <ch...@kaltepoth.de>
> > > >To: dev@deltaspike.apache.org
> > > >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
> > > >>> > christian@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 <jo...@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 <
> > > nickarls@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 <
> > > struberg@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 <ch...@kaltepoth.de>
> > > >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > >>> > > > > > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@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 <ge...@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 <st...@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 <ch...@kaltepoth.de>
> > >To: dev@deltaspike.apache.org
> > >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
> > >>> > christian@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 <jo...@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 <
> > nickarls@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 <
> > struberg@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 <ch...@kaltepoth.de>
> > >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > >>> > > > > > deltaspike-dev@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
Re: Servlet module prototype
Posted by Gerhard Petracek <ge...@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 <st...@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 <ch...@kaltepoth.de>
> >To: dev@deltaspike.apache.org
> >Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
> >>> > christian@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 <jo...@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 <
> nickarls@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 <
> struberg@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 <ch...@kaltepoth.de>
> >>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> >>> > > > > > deltaspike-dev@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.
> >>> > > :)
>
Re: Servlet module prototype
Posted by Mark Struberg <st...@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 <ch...@kaltepoth.de>
>To: dev@deltaspike.apache.org
>Cc: Mark Struberg <st...@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 <rm...@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 <ch...@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 <jo...@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 <
>>> > christian@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 <jo...@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 <nickarls@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 <st...@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 <ch...@kaltepoth.de>
>>> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
>>> > > > > > deltaspike-dev@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.
>>> > > :)
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@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 <rm...@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 <ch...@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 <jo...@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 <
> > > christian@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 <jo...@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 <
> nickarls@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 <
> struberg@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 <ch...@kaltepoth.de>
> > > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > > > > deltaspike-dev@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
Re: Servlet module prototype
Posted by Romain Manni-Bucau <rm...@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 <ch...@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 <jo...@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 <
> > christian@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 <jo...@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 <nickarls@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 <st...@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 <ch...@kaltepoth.de>
> > > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > > > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@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 <jo...@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 <
> christian@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 <jo...@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 <ni...@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 <st...@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 <ch...@kaltepoth.de>
> > > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > > deltaspike-dev@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
Re: Servlet module prototype
Posted by "John D. Ament" <jo...@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 <christian@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 <jo...@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 <ni...@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 <st...@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 <ch...@kaltepoth.de>
> > > > > To: "deltaspike-dev@incubator.apache.org" <
> > > > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
@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 <jo...@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 <ni...@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 <st...@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 <ch...@kaltepoth.de>
> > > > To: "deltaspike-dev@incubator.apache.org" <
> > > deltaspike-dev@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
Re: Servlet module prototype
Posted by "John D. Ament" <jo...@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 <ni...@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 <st...@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 <ch...@kaltepoth.de>
> > > To: "deltaspike-dev@incubator.apache.org" <
> > deltaspike-dev@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
>
Re: Servlet module prototype
Posted by Nicklas Karlsson <ni...@gmail.com>.
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 <st...@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 <ch...@kaltepoth.de>
> > To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@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
Re: Servlet module prototype
Posted by Mark Struberg <st...@yahoo.de>.
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 <ch...@kaltepoth.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@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
>