I found another case were something like
@DeltaSpike/@DeltaSpikeManaged/etc. would probably be a better name:
@JsfPhaseListener public class MyPhaseListener implements PhaseListener {
... }
It's the same as with @Web.
We already know that it's an PhaseListener. So why name the annotation the
same again?
We also already know that a HttpServletRequest is something from the Web...
2014-01-07 17:44 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>:
> In the CDI 1.1 specs (3.7), there are only following beans defined:
> HttpServletRequest
> HttpSession
> ServletContext
>
> So if you are in a CDI 1.1 environment, it might be confusing because some
> artifacts are available without @Web and some only with @Web.
> I will open a vote about it because i can't see a reason to keep @Web
>
>
>
> 2014/1/5 Karl Kildén <karl.kil...@gmail.com>
>
>> This is my summary:
>>
>> By following the discussion it seems to be seen as convenient vs
>> inconvenient and the vote is kinda even. What I would like to see is
>> cohesion in Deltaspike overall. Either you use namespaces or you don't. My
>> point is basically that it feels more like a project-wide decision.
>>
>> To summarize, when a spec or w/e is expected to introduce the same
>> producer
>> different strategies can be used. So either the strategy as a user is to
>> a)
>> use the namespace and drop it when someone else provides it (i.e a spec)
>> or
>> b) Trust Deltaspike to handle any conflicts.
>>
>> pros:
>> - No conflicts or conflict management.
>> - Users can use both variants for example if Deltaspike offers extras.
>> Apparently already true for Servlet Module.
>> - Abolishes the idea of transparent replacement with the argument that
>> various enhancements might make it incompatible anyways.
>>
>> cons:
>> - Must remove namespace when Deltaspike is superfluous. No namespace and
>> automatic veto would make it more seamless.
>> - More verbose and not as pretty to use.
>> - Does not see incompatibly as a big problem. Reasoning is: End user must
>> test application behavior after upgrade anyway and problems should be
>> minor.
>>
>> Btw i'm +0
>>
>>
>> On 4 January 2014 17:09, Gerhard Petracek <gerhard.petra...@gmail.com
>> >wrote:
>>
>> > to summarize it:
>> > so far we haven't seen a real blocker for dropping the qualifier.
>> >
>> > regards,
>> > gerhard
>> >
>> >
>> >
>> > 2014/1/4 Romain Manni-Bucau <rmannibu...@gmail.com>
>> >
>> > > never said it was blocking, just it shouldn't be done blindly and docs
>> > > should be very explicit on it and potential conflict (usually we don't
>> > > care to not mention we don't use a qualifier, here we do).
>> > > Romain Manni-Bucau
>> > > Twitter: @rmannibucau
>> > > Blog: http://rmannibucau.wordpress.com/
>> > > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > Github: https://github.com/rmannibucau
>> > >
>> > >
>> > >
>> > > 2014/1/4 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> > > > it was just one of several possibilities you have.
>> > > > in any case, the special case you mentioned is still easy enough ->
>> > there
>> > > > is no issue/blocker imo.
>> > > >
>> > > > regards,
>> > > > gerhard
>> > > >
>> > > >
>> > > >
>> > > > 2014/1/4 Romain Manni-Bucau <rmannibu...@gmail.com>
>> > > >
>> > > >> so didnt get your comment on decorators...
>> > > >> Romain Manni-Bucau
>> > > >> Twitter: @rmannibucau
>> > > >> Blog: http://rmannibucau.wordpress.com/
>> > > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > >> Github: https://github.com/rmannibucau
>> > > >>
>> > > >>
>> > > >>
>> > > >> 2014/1/4 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> > > >> > @romain:
>> > > >> > you should do the wrapping like you would do it without cdi
>> anyway.
>> > > >> >
>> > > >> > regards,
>> > > >> > gerhard
>> > > >> >
>> > > >> >
>> > > >> >
>> > > >> > 2014/1/4 Romain Manni-Bucau <rmannibu...@gmail.com>
>> > > >> >
>> > > >> >> @gerhard: @Decorator is broken in 85% of the case and doesn't
>> work
>> > > >> >> with producers IIRC
>> > > >> >> Romain Manni-Bucau
>> > > >> >> Twitter: @rmannibucau
>> > > >> >> Blog: http://rmannibucau.wordpress.com/
>> > > >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > >> >> Github: https://github.com/rmannibucau
>> > > >> >>
>> > > >> >>
>> > > >> >>
>> > > >> >> 2014/1/4 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> > > >> >> > @romain:
>> > > >> >> > you can use e.g. @Decorator in such special cases or just do
>> the
>> > > >> wrapping
>> > > >> >> > like you would without cdi.
>> > > >> >> >
>> > > >> >> > regards,
>> > > >> >> > gerhard
>> > > >> >> >
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > 2014/1/4 Romain Manni-Bucau <rmannibu...@gmail.com>
>> > > >> >> >
>> > > >> >> >> yes and no, depend what you do of it, the point is if you
>> base
>> > > your
>> > > >> >> >> app on CDI (as much as possible I mean) and it starts to be
>> > > common,
>> > > >> >> >> you can put logic in these producers, typically wrapping of
>> > > >> >> >> requests/responses (can be easier than using filters) and in
>> > this
>> > > >> case
>> > > >> >> >> this is often not 1-1 replacement. I know it is doable but
>> needs
>> > > to
>> > > >> >> >> update the app and can break "big apps" where you aggregate
>> > > multiple
>> > > >> >> >> parts.
>> > > >> >> >>
>> > > >> >> >> Having a namespace should be a best practise IMHO.
>> > > >> >> >> Romain Manni-Bucau
>> > > >> >> >> Twitter: @rmannibucau
>> > > >> >> >> Blog: http://rmannibucau.wordpress.com/
>> > > >> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > >> >> >> Github: https://github.com/rmannibucau
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >> >>
>> > > >> >> >> 2014/1/4 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> > > >> >> >> > @romain:
>> > > >> >> >> > i don't see an issue here - if you add the
>> ds-servlet-module,
>> > > you
>> > > >> just
>> > > >> >> >> drop
>> > > >> >> >> > your own producers (which overlap and should do the same
>> > > anyway).
>> > > >> >> >> >
>> > > >> >> >> > regards,
>> > > >> >> >> > gerhard
>> > > >> >> >> >
>> > > >> >> >> >
>> > > >> >> >> >
>> > > >> >> >> > 2014/1/4 Romain Manni-Bucau <rmannibu...@gmail.com>
>> > > >> >> >> >
>> > > >> >> >> >> well in fact I saw a lot of cdi 1.0 app producing http*
>> > objects
>> > > >> >> >> >> without qualifier cause it was missing in cdi so conflicts
>> > can
>> > > >> occurs
>> > > >> >> >> >> and are quite common
>> > > >> >> >> >> Romain Manni-Bucau
>> > > >> >> >> >> Twitter: @rmannibucau
>> > > >> >> >> >> Blog: http://rmannibucau.wordpress.com/
>> > > >> >> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > > >> >> >> >> Github: https://github.com/rmannibucau
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >> >> 2014/1/4 Gerhard Petracek <gerhard.petra...@gmail.com>:
>> > > >> >> >> >> > we had no qualifier for FacesContext (in codi,
>> seam3,...).
>> > > >> since it
>> > > >> >> >> used
>> > > >> >> >> >> to
>> > > >> >> >> >> > be a common producer, we saw "compatibility issues".
>> > > >> >> >> >> > however, with a proper documentation (how to veto one of
>> > > them),
>> > > >> no
>> > > >> >> >> user
>> > > >> >> >> >> > (i'm aware of) had a real issue with it and for the
>> > majority
>> > > it
>> > > >> was
>> > > >> >> >> >> easier
>> > > >> >> >> >> > to use (because there wasn't an issue at all).
>> > > >> >> >> >> >
>> > > >> >> >> >> > regards,
>> > > >> >> >> >> > gerhard
>> > > >> >> >> >> >
>> > > >> >> >> >> >
>> > > >> >> >> >> >
>> > > >> >> >> >> > 2014/1/4 Mark Struberg <strub...@yahoo.de>
>> > > >> >> >> >> >
>> > > >> >> >> >> >>
>> > > >> >> >> >> >>
>> > > >> >> >> >> >> The question for me is: are there already known
>> producers
>> > > for
>> > > >> it
>> > > >> >> or
>> > > >> >> >> is
>> > > >> >> >> >> >> there any spec which introduces this?
>> > > >> >> >> >> >> In that case a custom qualifier is always a good idea
>> imo.
>> > > >> >> Otherwise
>> > > >> >> >> we
>> > > >> >> >> >> >> would face different behaviour on different containers.
>> > They
>> > > >> most
>> > > >> >> >> times
>> > > >> >> >> >> >> behave different...
>> > > >> >> >> >> >> I just would like to avoid possible incompatibilities.
>> And
>> > > for
>> > > >> >> this a
>> > > >> >> >> >> >> Qualifier certainly works great - without much
>> additional
>> > > >> >> complexity.
>> > > >> >> >> >> >>
>> > > >> >> >> >> >> Does all the needed detection + veto really pay off?
>> How
>> > do
>> > > you
>> > > >> >> know
>> > > >> >> >> you
>> > > >> >> >> >> >> are running in an environment which already has such a
>> > > producer
>> > > >> >> >> >> registered?
>> > > >> >> >> >> >> This is not easy to accomplish!
>> > > >> >> >> >> >>
>> > > >> >> >> >> >>
>> > > >> >> >> >> >> Thus I'm for keeping it.
>> > > >> >> >> >> >>
>> > > >> >> >> >> >>
>> > > >> >> >> >> >> LieGrue,
>> > > >> >> >> >> >> strub
>> > > >> >> >> >> >>
>> > > >> >> >> >> >>
>> > > >> >> >> >> >>
>> > > >> >> >> >> >>
>> > > >> >> >> >> >> >________________________________
>> > > >> >> >> >> >> > From: Gerhard Petracek <gerhard.petra...@gmail.com>
>> > > >> >> >> >> >> >To: dev@deltaspike.apache.org
>> > > >> >> >> >> >> >Sent: Saturday, 4 January 2014, 12:57
>> > > >> >> >> >> >> >Subject: Re: Servlet Module - Do we really need @Web?
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >+1 for a veto in case of cdi 1.1.
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >@external producers:
>> > > >> >> >> >> >> >we can document it (how users can veto e.g.
>> producers, if
>> > > they
>> > > >> >> see
>> > > >> >> >> any
>> > > >> >> >> >> >> >overlap).
>> > > >> >> >> >> >> >however, deltaspike shouldn't add complexity just
>> because
>> > > >> there
>> > > >> >> >> might
>> > > >> >> >> >> be a
>> > > >> >> >> >> >> >custom producer (for the same).
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >regards,
>> > > >> >> >> >> >> >gerhard
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >2014/1/4 Christian Kaltepoth <christ...@kaltepoth.de>
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >> @John: Actually the Servlet module provides more
>> than
>> > > what
>> > > >> CDI
>> > > >> >> 1.1
>> > > >> >> >> >> adds.
>> > > >> >> >> >> >> >> For example the event propagation and the recently
>> > added
>> > > >> >> >> "WebStorage"
>> > > >> >> >> >> >> for
>> > > >> >> >> >> >> >> the resource loading and so on. So people may want
>> to
>> > add
>> > > >> the
>> > > >> >> >> Servlet
>> > > >> >> >> >> >> >> module even in a CDI 1.1 container.
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >> I'm also +0 for that. Of cause it would be nice to
>> get
>> > > rid
>> > > >> of
>> > > >> >> >> @Web.
>> > > >> >> >> >> For
>> > > >> >> >> >> >> the
>> > > >> >> >> >> >> >> CDI 1.1 case we could actually veto our produces as
>> > > Thomas
>> > > >> >> >> suggested.
>> > > >> >> >> >> >> But
>> > > >> >> >> >> >> >> what about other portable extensions that may have
>> > > producers
>> > > >> >> for
>> > > >> >> >> >> >> @Default.
>> > > >> >> >> >> >> >> Say I'm using CDI 1.0 and also have Solder on the
>> > > >> classpath. I
>> > > >> >> >> think
>> > > >> >> >> >> >> Solder
>> > > >> >> >> >> >> >> is still a common dependency of some libraries,
>> > correct?
>> > > In
>> > > >> >> some
>> > > >> >> >> >> regard
>> > > >> >> >> >> >> it
>> > > >> >> >> >> >> >> is nice to have a custom "namespace" for the
>> producers.
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >> 2014/1/3 Thomas Andraschko <
>> > andraschko.tho...@gmail.com>
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >> > Because our customers have different servers
>> (tomcat7
>> > > and
>> > > >> >> even
>> > > >> >> >> 6,
>> > > >> >> >> >> >> >> > glassfish, jboss), so it would be a great
>> enhancement
>> > > for
>> > > >> >> >> product
>> > > >> >> >> >> >> >> > development.
>> > > >> >> >> >> >> >> >
>> > > >> >> >> >> >> >> >
>> > > >> >> >> >> >> >> > 2014/1/3 John D. Ament <john.d.am...@gmail.com>
>> > > >> >> >> >> >> >> >
>> > > >> >> >> >> >> >> > > If you're in servlet 3.1/CDI 1.1 you don't even
>> > need
>> > > the
>> > > >> >> >> servlet
>> > > >> >> >> >> >> >> > > module (so why include it as a dependency?)
>> > > >> >> >> >> >> >> > >
>> > > >> >> >> >> >> >> > > On Fri, Jan 3, 2014 at 1:09 PM, Romain
>> Manni-Bucau
>> > > >> >> >> >> >> >> > > <rmannibu...@gmail.com> wrote:
>> > > >> >> >> >> >> >> > > > -0 both injections can be different depending
>> on
>> > > >> >> containers
>> > > >> >> >> >> using
>> > > >> >> >> >> >> >> some
>> > > >> >> >> >> >> >> > > > advanced stuff out of ee but affecting ee
>> > lifecycle
>> > > >> (at
>> > > >> >> >> least
>> > > >> >> >> >> in
>> > > >> >> >> >> >> >> > tomcat)
>> > > >> >> >> >> >> >> > > > but your proposal sounds acceptable.
>> > > >> >> >> >> >> >> > > > Le 3 janv. 2014 17:58, "Thomas Andraschko" <
>> > > >> >> >> >> >> >> > andraschko.tho...@gmail.com>
>> > > >> >> >> >> >> >> > > a
>> > > >> >> >> >> >> >> > > > écrit :
>> > > >> >> >> >> >> >> > > >
>> > > >> >> >> >> >> >> > > >> Hi,
>> > > >> >> >> >> >> >> > > >>
>> > > >> >> >> >> >> >> > > >> IMHO @Web is somehow annoying.
>> > > >> >> >> >> >> >> > > >> HttpServlet e.g. is always "web", so @Web is
>> > just
>> > > a
>> > > >> >> >> overhead
>> > > >> >> >> >> and
>> > > >> >> >> >> >> >> > doesn't
>> > > >> >> >> >> >> >> > > >> look nice.
>> > > >> >> >> >> >> >> > > >>
>> > > >> >> >> >> >> >> > > >> Can't we just veto the producers if CDI1.1 is
>> > > >> available?
>> > > >> >> >> >> >> >> > > >> The code would be the same with CDI 1.0 + DS,
>> > CDI
>> > > 1.1
>> > > >> >> >> without
>> > > >> >> >> >> or
>> > > >> >> >> >> >> >> with
>> > > >> >> >> >> >> >> > > DS.
>> > > >> >> >> >> >> >> > > >>
>> > > >> >> >> >> >> >> > > >> Regards,
>> > > >> >> >> >> >> >> > > >> Thomas
>> > > >> >> >> >> >> >> > > >>
>> > > >> >> >> >> >> >> > >
>> > > >> >> >> >> >> >> >
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >> --
>> > > >> >> >> >> >> >> Christian Kaltepoth
>> > > >> >> >> >> >> >> Blog: http://blog.kaltepoth.de/
>> > > >> >> >> >> >> >> Twitter: http://twitter.com/chkal
>> > > >> >> >> >> >> >> GitHub: https://github.com/chkal
>> > > >> >> >> >> >> >>
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >> >
>> > > >> >> >> >> >>
>> > > >> >> >> >>
>> > > >> >> >>
>> > > >> >>
>> > > >>
>> > >
>> >
>>
>
>
