+1
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-23 23:31 GMT+01:00 Thomas Andraschko :
> Hmm. So i would just start with 1) and we can continue our discussion after
Hmm. So i would just start with 1) and we can continue our discussion after
the poll. Ok?
2014-02-23 23:28 GMT+01:00 Romain Manni-Bucau :
> wonder if 2 is really a *public* question once 1 is decided
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedI
maybe we can do a public poll?
1) Keep it like it
2) @DeltaSpike
3) ordinal()
4) other?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-23 23:18 GMT+01:00 Thomas Andra
wonder if 2 is really a *public* question once 1 is decided
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-23 23:26 GMT+01:00 Thomas Andraschko :
> Shoudln't we do 2 p
Shoudln't we do 2 polls?
1) Should we introduce a global qualifier instead @web? If yes, which name?
2) Alternative for JsfPhaseListener?
- keep it as it is
- just rename it as it redudant
- use the global qualifier + introduce a second annotation for setting
the ordinal
2014-02-23
If it was agreed, we should leave @JsfPhaseListener as it is...
Sorry if i'm a bit annoying but...
I still like the idea of a global qualifier instead @Web.
As Romain said, it would see it as an namespace ->
@Inject @DeltaSpike ServletContext context
looks good.
2014-02-23 23:01 GMT+01:00 Gerh
at other parts you specify an artifact with an interface, annotation,...
and at the same point (if possible) you are able to specify the ordinal
(without an extra annotation).
that's easier for users and therefore we agreed on it in the beginning.
regards,
gerhard
http://www.irian.at
Your JSF/Ja
which consistency gerhard?
2014-02-23 22:45 GMT+01:00 Gerhard Petracek :
> independent of the name, we would break the consistency.
>
> regards,
> gerhard
>
> http://www.irian.at
>
> Your JSF/JavaEE powerhouse -
> JavaEE Consulting, Development and
> Courses in English and German
>
> Professiona
independent of the name, we would break the consistency.
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2014-02-23 22:40 GMT+01:00 Romain Manni-Bucau :
> using javax.*
using javax.* from deltaspike is quite ambiguous: is it a DS behavior
or a spec one? I'm no opposed Priority but in
org.apache.deltaspile...Priority
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://githu
Could you explain this? I can't follow you.
2014-02-23 22:23 GMT+01:00 Romain Manni-Bucau :
> I'd prefer something more explicit. Just changing the package would be
> enough for me
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linked
I'd prefer something more explicit. Just changing the package would be
enough for me
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-23 22:17 GMT+01:00 Thomas Andraschk
Hmm...
We could clone it for JEE6 support and handle both annotations for backward
compatibility.
Maybe we could also use it for other features (or later..)
2014-02-23 22:14 GMT+01:00 Romain Manni-Bucau :
> That's would be ambiguous with JavaEE 6
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Bl
That's would be ambiguous with JavaEE 6
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-23 22:12 GMT+01:00 Thomas Andraschko :
> What about reusing javax.annotation.Pri
What about reusing javax.annotation.Priority?
2014-02-23 22:02 GMT+01:00 Gerhard Petracek :
> it's just a stereotype to get a better tool-support...
> @Advanced is also a qualifier (at least in codi).
>
> however, we need "ordinal" or we add @InvocationOrder as it was in codi.
> once we do that,
it's just a stereotype to get a better tool-support...
@Advanced is also a qualifier (at least in codi).
however, we need "ordinal" or we add @InvocationOrder as it was in codi.
once we do that, we break the consistency in that area.
regards,
gerhard
http://www.irian.at
Your JSF/JavaEE powerhou
Another problem is that @web is a qualifier and @JsfPhaseListener is a
stereotype and not a qualifier.
So if we would change it, we must use different annotations. Right?
IMO
@Inject @DeltaSpike ServletContext context;
would be great as it's just like a namespace.
For the @JsfPhaseListener, some
IMO it's actually more expressive than any other names. Maybe
@DeltaSpikeManaged would be more impressive...
+1 @DeltaSpike then, before keeping the old redudant/"ugly" qualifiers.
2014-02-18 10:51 GMT+01:00 Romain Manni-Bucau :
> +1 kind of tradeoff
> Romain Manni-Bucau
> Twitter: @rmannibu
+1 kind of tradeoff
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 10:46 GMT+01:00 Gerhard Petracek :
> we haven't seen a nice name so far -> i would keep what we h
we haven't seen a nice name so far -> i would keep what we have right now
(it's redundant, but at least a bit more expressive).
regards,
gerhard
2014-02-18 10:20 GMT+01:00 Mark Struberg :
> I do agree on @Managed not being very expressive. Think about the
> @ManagedBean disaster in JavaEE itse
I do agree on @Managed not being very expressive. Think about the @ManagedBean
disaster in JavaEE itself. 'Managed' is in the same ballpark like 'Class' or
'Object'.
Managed by whom and what?
In that case I'd rather go with @DeltaSpike or keep @Web...
But I do not care that much about names...
t;> >> >> > > > > >> > > >> 2014/1/4 Gerhard Petracek <
>> >> >> gerhard.petra...@gmail.com
>> >> >> >> >:
>> >> >> >> >> > > > > >> > > >> > @romain:
>> &
;> > > > > >> > > >> >
> >> >> >> >> > > > > >> > > >> >
> >> >> >> >> > > > > >> > > >> >
> >> >> >> >> > > >
>> >
>> >> >> >> > > > > >> > > >> >> @gerhard: @Decorator is broken in 85% of the
>> >> case
>> >> >> and
>> >>
> >> >> LinkedIn:
> http://fr.linkedin.com/in/rmannibucau
> >> >> >> > > > > >> > > >> >> Github: https://github.com/rmannibucau
> >> >> >> > > > > >> > > >> >>
>
> >> >>
>> >> >> > > > > >> > > >> >>
>> >> >> > > > > >> > > >> >> 2014/1/4 Gerhard Petracek <
>> >> gerhard.petra...@gmail.com
>> >> >> >:
>> >&g
t;:
> > >> >> > > > > >> > > >> >> > @romain:
> > >> >> > > > > >> > > >> >> > you can use e.g. @D
gt;> >
> >> >> > > > > >> > > >> >> > regards,
> >> >> > > > > >> > > >> >> > gerhard
> >> >> &g
gt;> > > >> >> >
>> >> > > > > >> > > >> >> >
>> >> > > > > >> > > >> >> >
>> >> > > > > >> > > >> >> > 2014/1/4 R
) and it
> >> starts
> >> > > to
> >> > > > be
> >> > > > > >> > > common,
> >> > > > > >> > > >> >> >> you can put logic in these producers, typical
t; > > > in
>> > > > > >> > this
>> > > > > >> > > >> case
>> > > > > >> > > >> >> >> this is often not 1-1 replacement. I know it is
>> &
and can break "big apps" where you
> > > > aggregate
> > > > > >> > > multiple
> > > > > >> > > >> >> >> parts.
> > > > > >> > > >> >> >>
> > >
> >> >> >> Blog: http://rmannibucau.wordpress.com/
> > > > >> > > >> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > > >> > > >> >> >> Github: https://github.com/rmannibucau
>> >> >>
> > > >> > > >> >> >>
> > > >> > > >> >> >> 2014/1/4 Gerhard Petracek >:
> > > >> > > >> >> >> > @romain:
> > > >> > > >> >> >> &g
;> > > >> >> >> > @romain:
> > >> > > >> >> >> > i don't see an issue here - if you add the
> > >> ds-servlet-module,
> > >> > > you
> > >> > > >> just
> > >> > > >> >> >> drop
> > >> > > >> >> >> > your own producers (which overlap a
; > > >> >> >> >
> >> > > >> >> >> >
> >> > > >> >> >> > 2014/1/4 Romain Manni-Bucau
> >> > > >> >> >> >
> >> > > >> &
t;
>> > > >> >> >> > 2014/1/4 Romain Manni-Bucau
>> > > >> >> >> >
>> > > >> >> >> >> 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
>> > > >
p://rmannibucau.wordpress.com/
> > > >> >> >> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > > >> >> >> >> Github: https://github.com/rmannibucau
> > > >> >> >> >>
> > > >> >>
gt;> >>
> > >> >> >> >>
> > >> >> >> >> 2014/1/4 Gerhard Petracek :
> > >> >> >> >> > we had no qualifier for FacesContext (in codi, seam3,...).
> > >> since it
>
mon producer, we saw "compatibility issues".
> >> >> >> >> > however, with a proper documentation (how to veto one of
> them),
> >> no
> >> >> >> user
> >> >> >> >> > (i'm aware of)
ne of them),
>> no
>> >> >> user
>> >> >> >> > (i'm aware of) had a real issue with it and for the majority it
>> was
>> >> >> >> easier
>> >> >> >> > to use (because the
> to use (because there wasn't an issue at all).
> >> >> >> >
> >> >> >> > regards,
> >> >> >> > gerhard
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >>
>> >> > regards,
>> >> >> > gerhard
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > 2014/1/4 Mark Struberg
>> >> >> >
>> >> >> >>
gt;> >
> >> >> >>
> >> >> >>
> >> >> >> 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
r 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
>>
ier 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
> >> regi
gt; >> 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 envir
+1 Gerhard!
@romain
users can easily remove their own producers. It just takes 2 min to remove
this code, which is already available in DS then.
Maybe another qualifier would be better, too -> @DeltaSpike,
DeltaSpikeManaged etc.
I really don't like @Web as servlet objects are already related to w
ection + 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
> >>
> >>
&
sy to accomplish!
>>
>>
>> Thus I'm for keeping it.
>>
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> >
>> > From: Gerhard Petracek
>> >To: dev@deltaspike.apache.org
>> >
_
> > From: Gerhard Petracek
> >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 d
accomplish!
Thus I'm for keeping it.
LieGrue,
strub
>
> From: Gerhard Petracek
>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
+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
> @
@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 ni
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
> 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, Ja
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
wrote:
> -0 both injections can be different depending on containers using some
> advanced stuff out of ee but affecting ee lifecycle (at
-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" a
écrit :
> Hi,
>
> IMHO @Web is somehow annoying.
> HttpServlet e.g. is
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
58 matches
Mail list logo
