i'm ok with changing it, if we do it for both. however, we would need a better name (imo without the project-name).
regards, gerhard 2014-02-15 11:24 GMT+01:00 Thomas Andraschko <andraschko.tho...@gmail.com>: > 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 > >> > > >> >> >> >> >> >> > >> > > >> >> >> >> >> > > >> > > >> >> >> >> >> > > >> > > >> >> >> >> >> > >> > > >> >> >> >> > >> > > >> >> >> > >> > > >> >> > >> > > >> > >> > > > >> > > >> > > > > >