subject:"Re\: Servlet module prototype"

Re: Servlet module prototype

2013-06-12 Thread Mark Struberg

cool, txs!

Will review those 2 new modules (bv + servlet) later today.

LieGrue,
strub




- Original Message -
> From: Christian Kaltepoth 
> To: [email protected]
> 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 
> 
>>  +1 as well, looks good to me.
>> 
>> 
>>  On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg  
> 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 
>>  > > To: [email protected]
>>  > > 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 
>>  > >
>>  > >>  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 
>>  > >>
>>  > >>  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
>>  > >>>  functional

Re: Servlet module prototype

2013-06-12 Thread Christian Kaltepoth

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 

> +1 as well, looks good to me.
>
>
> On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg  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 
> > > To: [email protected]
> > > 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 
> > >
> > >>  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 
> > >>
> > >>  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 c

Re: Servlet module prototype

2013-06-11 Thread John D. Ament

+1 as well, looks good to me.


On Tue, Jun 11, 2013 at 12:12 PM, Mark Struberg  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 
> > To: [email protected]
> > 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 
> >
> >>  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 
> >>
> >>  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
> >>>
> >>>
>

Re: Servlet module prototype

2013-06-11 Thread Mark Struberg

+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 
> To: [email protected]
> 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 
> 
>>  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 
>> 
>>  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 <
>>>  [email protected]
>>>  > 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 modul

Re: Servlet module prototype

2013-06-11 Thread Christian Kaltepoth

struction 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 
>> >
>> > > 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 
>> > >
>> > > > @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 
>> > > >
>> > > > > the general jira-issue for it is [1].
>> > > > >
>> > > > > regards,
>> > > > > gerhard
>> > > > >
>> > > > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
>> > > > >
>> > > > >
>> > > > >
>> > > > > 2013/6/7 Mark Struberg 
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > 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 /*the 'feature'*/,
>> Set>
>> > > > > > /*types which get observed*/
>> > > > > >
>> > > > > > and utilize @Observes ProcessObserverMethod to check whether
>> there
>> > > is a
>> >

Re: Servlet module prototype

2013-06-08 Thread Christian Kaltepoth

ad 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 
> > >
> > > > @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 
> > > >
> > > > > the general jira-issue for it is [1].
> > > > >
> > > > > regards,
> > > > > gerhard
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
> > > > >
> > > > >
> > > > >
> > > > > 2013/6/7 Mark Struberg 
> > > > >
> > > > > >
> > > > > >
> > > > > > 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 /*the 'feature'*/,
> Set>
> > > > > > /*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 
> > > > > > >To: [email protected]
> > > > > > >Cc: Mark Struberg 
> > > > > > >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
> > >

Re: Servlet module prototype

2013-06-07 Thread John D. Ament

gt; > @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 
> > >
> > > > the general jira-issue for it is [1].
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
> > > >
> > > >
> > > >
> > > > 2013/6/7 Mark Struberg 
> > > >
> > > > >
> > > > >
> > > > > 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 /*the 'feature'*/, Set>
> > > > > /*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 
> > > > > >To: [email protected]
> > > > > >Cc: Mark Struberg 
> > > > > >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 
> > > > > >
> > > > > >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*
> &g

Re: Servlet module prototype

2013-06-07 Thread Christian Kaltepoth

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 

> 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 
>
> > @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 
> >
> > > the general jira-issue for it is [1].
> > >
> > > regards,
> > > gerhard
> > >
> > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
> > >
> > >
> > >
> > > 2013/6/7 Mark Struberg 
> > >
> > > >
> > > >
> > > > 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 /*the 'feature'*/, Set>
> > > > /*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
>

Re: Servlet module prototype

2013-06-07 Thread Romain Manni-Bucau

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 

> @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 
>
> > the general jira-issue for it is [1].
> >
> > regards,
> > gerhard
> >
> > [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
> >
> >
> >
> > 2013/6/7 Mark Struberg 
> >
> > >
> > >
> > > 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 /*the 'feature'*/, Set>
> > > /*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 
> > > >To: [email protected]
> > > >Cc: Mark Struberg 
> > > >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 
> > > >
> > > >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*
> > > &

Re: Servlet module prototype

2013-06-07 Thread Christian Kaltepoth

@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 

> the general jira-issue for it is [1].
>
> regards,
> gerhard
>
> [1] https://issues.apache.org/jira/browse/DELTASPIKE-349
>
>
>
> 2013/6/7 Mark Struberg 
>
> >
> >
> > 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 /*the 'feature'*/, Set>
> > /*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 
> > >To: [email protected]
> > >Cc: Mark Struberg 
> > >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 
> > >
> > >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 
> > >>
> > >>> 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 .
> > >>>
> > >>> 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:
> > >>>
> > >>>

Re: Servlet module prototype

2013-06-07 Thread Gerhard Petracek

the general jira-issue for it is [1].

regards,
gerhard

[1] https://issues.apache.org/jira/browse/DELTASPIKE-349



2013/6/7 Mark Struberg 

>
>
> 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 /*the 'feature'*/, Set>
> /*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 
> >To: [email protected]
> >Cc: Mark Struberg 
> >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 
> >
> >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 
> >>
> >>> 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 .
> >>>
> >>> 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:
> >>>
> >>>   
> >>>
> org.apache.deltaspike.DISABLE_SERVLET_EVENTS
> >>> true
> >>>   
> >>>
> >>> 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 
> >>>
> >>> > What if the web-fragment.xml were in a separate JAR?
> >>> > Deactivatable is a custom solution, I'd love to avo

Re: Servlet module prototype

2013-06-07 Thread Mark Struberg



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 /*the 'feature'*/, Set> /*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 
>To: [email protected] 
>Cc: Mark Struberg  
>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 
>
>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 
>>
>>> 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 .
>>>
>>> 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:
>>>
>>>   
>>>     org.apache.deltaspike.DISABLE_SERVLET_EVENTS
>>>     true
>>>   
>>>
>>> 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 
>>>
>>> > 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 <
>>> > [email protected]
>>> > > 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 D

Re: Servlet module prototype

2013-06-07 Thread Ove Ranheim

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  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 
> 
>> 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 *
>> *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 
>> 
>>> 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 .
>>> 
>>> 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:
>>> 
>>>  
>>>org.apache.deltaspike.DISABLE_SERVLET_EVENTS
>>>true
>>>  
>>> 
>>> 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 
>>> 
 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 <
 [email protected]
> 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 
> 
>> 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 <
>> [email protected]
 
>> 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

Re: Servlet module prototype

2013-06-06 Thread Romain Manni-Bucau

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 *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/6/7 Christian Kaltepoth 

> 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 
>
> > 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 *
> > *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 
> >
> > > 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 .
> > >
> > > 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:
> > >
> > >   
> > >
> org.apache.deltaspike.DISABLE_SERVLET_EVENTS
> > > true
> > >   
> > >
> > > 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 
> > >
> > > > 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 <
> > > > [email protected]
> > > > > 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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Servlet module prototype

2013-06-06 Thread Christian Kaltepoth

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 

> 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 *
> *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 
>
> > 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 .
> >
> > 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:
> >
> >   
> > org.apache.deltaspike.DISABLE_SERVLET_EVENTS
> > true
> >   
> >
> > 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 
> >
> > > 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 <
> > > [email protected]
> > > > 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 
> > > >
> > > > > 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 <
> [email protected]
> > >
> > > > > 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 <
> [email protected]>
> > > > > wrote:
> > > > > >
> > > > > > > Nice work!
> > > > > > >
> > > > > > > The @Web Qualifier looks a bit odd, but will turn

Re: Servlet module prototype

2013-06-06 Thread Romain Manni-Bucau

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 *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/6/7 Christian Kaltepoth 

> 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 .
>
> 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:
>
>   
> org.apache.deltaspike.DISABLE_SERVLET_EVENTS
> true
>   
>
> 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 
>
> > 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 <
> > [email protected]
> > > 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 
> > >
> > > > 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  >
> > > > 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 
> > > > 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 
> > > > > > > To: "[email protected]" <
> > > > > > [email protected]>
> > > > > > > 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
> > >

Re: Servlet module prototype

2013-06-06 Thread Christian Kaltepoth

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 .

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:

  
org.apache.deltaspike.DISABLE_SERVLET_EVENTS
true
  

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 

> 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 <
> [email protected]
> > 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 
> >
> > > 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 
> > > 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 
> > > 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 
> > > > > > To: "[email protected]" <
> > > > > [email protected]>
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> >

Re: Servlet module prototype

2013-06-06 Thread John D. Ament

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  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 
>
> > 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 
> > 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 
> > 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 
> > > > > To: "[email protected]" <
> > > > [email protected]>
> > > > > 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

Re: Servlet module prototype

2013-06-06 Thread Christian Kaltepoth

@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 

> 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 
> 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 
> 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 
> > > > To: "[email protected]" <
> > > [email protected]>
> > > > 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
> >

Re: Servlet module prototype

2013-06-06 Thread John D. Ament

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  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  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 
> > > To: "[email protected]" <
> > [email protected]>
> > > 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

2013-06-06 Thread Nicklas Karlsson

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  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 
> > To: "[email protected]" <
> [email protected]>
> > 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

2013-06-06 Thread Mark Struberg

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 
> To: "[email protected]" 
> 
> 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
>

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

Re: Servlet module prototype

22 matches

Site Navigation

Mail list logo

Footer information