Fine thing. Although I see a few issues which I'd rather like to keep off core CDI as they are very easy to implement as portable Extensions (e.g. the XML config stuff CDI-123). We really must take care that we don't add things which bloats the CDI core spec with 20 pages which are hard to get right. Instead we should really focus on things which are fundamental basics and thus cannot be done via a portable Extension. LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Cc: > Sent: Thursday, October 6, 2011 2:21 AM > Subject: [cdi-dev] CDI 1.1 EDR1 posted :-) > > http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev >

________________________________ From: Rick Hightower <richardhightower(a)gmail.com&gt; To: Pete Muir <pmuir(a)redhat.com&gt; Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Friday, October 7, 2011 12:03 AM Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) I feel we need it too. I guess this goes without saying though.  On Thu, Oct 6, 2011 at 2:51 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: I've received a lot of feedback at JavaOne that XML config is something people want to see in the standard. So I would like to revisit this question. > >Feel free to discuss now, or I'll start with a proposal in a few weeks :-) > > >On 5 Oct 2011, at 23:43, Mark Struberg wrote: > >> Fine thing. >> >> Although I see a few issues which I'd rather like to keep off core CDI as they are very easy to implement as portable Extensions (e.g. the XML config stuff CDI-123). >> >> We really must take care that we don't add things which bloats the CDI core spec with 20 pages which are hard to get right. >> >> >> Instead we should really focus on things which are fundamental basics and thus cannot be done via a portable Extension. >> >> LieGrue, >> strub >> >> >> >> ----- Original Message ----- >>> From: Pete Muir <pmuir(a)redhat.com&gt; >>> To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>> Cc: >>> Sent: Thursday, October 6, 2011 2:21 AM >>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-) >>> >>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > > >_______________________________________________ >cdi-dev mailing list &gt;cdi-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/cdi-dev > -- Rick Hightower (415) 968-9037 Profile 

From: Mark Struberg <struberg(a)yahoo.de&gt; To: Rick Hightower <richardhightower(a)gmail.com>; Pete Muir <pmuir(a)redhat.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Friday, October 7, 2011 9:13 AM Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) I basically share the sentiments Gavin posted on in.relation.to. We could do it but we really should be picky and don't let the oldschool (call it 'unsexy') EJB and EE like styled XML schema make it into the spec but rather build on top of the namespace->package based syntax we had in the original CDI draft. BUT: 1.) we need to be aware that XML schemas are NOT that easy to change later! Thus if we see that we have forgotten something, then we are doomed for the future... And this situation is highly likely imo since getting this part right is not exactly easy. 2.) writing a water-safe spec for this might get pretty hard. Expect to add 20 more pages to our spec...  3.) There is one de-facto standard for it already, which is seam-XML. CODI nor any other CDI Extension project will introduce any similar stuff because Seam-XML is working fine and has a perfectly business friendly license. So I'm not sure which benefit writing it into the spec would bring. I see no benefit over the current situation for CDI containers nor end-users. Au contraire: if we hit an error in seam-xml, then it's easy to get this fixed centrally. LieGrue, strub > ________________________________ > From: Rick Hightower <richardhightower(a)gmail.com&gt; > To: Pete Muir <pmuir(a)redhat.com&gt; > Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Friday, October 7, 2011 12:03 AM > Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) > > > I feel we need it too. I guess this goes without saying though.  > > > > On Thu, Oct 6, 2011 at 2:51 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > I've received a lot of feedback at JavaOne that XML config is something people want to see in the standard. So I would like to revisit this question. >> >> Feel free to discuss now, or I'll start with a proposal in a few weeks :-) >> >> >> On 5 Oct 2011, at 23:43, Mark Struberg wrote: >> >>> Fine thing. >>> >>> Although I see a few issues which I'd rather like to keep off core CDI as they are very easy to implement as portable Extensions (e.g. the XML config stuff CDI-123). >>> >>> We really must take care that we don't add things which bloats the CDI core spec with 20 pages which are hard to get right. >>> >>> >>> Instead we should really focus on things which are fundamental basics and thus cannot be done via a portable Extension. >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>> To: cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>>> Cc: >>>> Sent: Thursday, October 6, 2011 2:21 AM >>>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-) >>>> >>>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >> >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > > > -- > Rick Hightower > (415) 968-9037 > Profile  > > > > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

From: Carlo de Wolf <cdewolf(a)redhat.com&gt; To: Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Friday, October 7, 2011 4:49 PM Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) On 10/07/2011 09:17 AM, Stuart Douglas wrote: > On 07/10/2011, at 6:13 PM, Mark Struberg wrote: > >> I basically share the sentiments Gavin posted on in.relation.to. We could do it but we really should be picky and don't let the oldschool (call it 'unsexy') EJB and EE like styled XML schema make it into the spec but rather build on top of the namespace->package based syntax we had in the original CDI draft. >> >> BUT: >> >> 1.) we need to be aware that XML schemas are NOT that easy to change later! Thus if we see that we have forgotten something, then we are doomed for the future... And this situation is highly likely imo since getting this part right is not exactly easy. >> >> >> 2.) writing a water-safe spec for this might get pretty hard. Expect to add 20 more pages to our spec... >> >> >> 3.) There is one de-facto standard for it already, which is seam-XML. CODI nor any other CDI Extension project will introduce any similar stuff because Seam-XML is working fine and has a perfectly business friendly license. So I'm not sure which benefit writing it into the spec would bring. I see no benefit over the current situation for CDI containers nor end-users. Au contraire: if we hit an error in seam-xml, then it's easy to get this fixed centrally. >> >> LieGrue, >> strub >> >> > I agree 100%. We already have a standards compliant and portable implementation of XML configuration, thanks to CDI portable extensions. I really don't see the benefit of writing this into the spec. > > Stuart While the implementation itself adheres to the CDI extension standard, it in itself is not a standard. The question I have is, would users and vendors want to have CDI extensions themselves be standardized? I think there is value in having some CDI extensions be certified. Not just being a de-facto. (Remember how Seam and Hibernate became de-jure.) Now this should in no way be attached to the CDI spec itself. Each extension spec should have its independent lifecycle, so it can be updated or deprecated at whim. I would even say that EJB 4 would make a nice case. (Although calling it EJB 4 would be so wrong. ;-) ) Carlo >> >>> ________________________________ >>> From: Rick Hightower&lt;richardhightower(a)gmail.com&gt; >>> To: Pete Muir&lt;pmuir(a)redhat.com&gt; >>> Cc: Mark Struberg&lt;struberg(a)yahoo.de&gt;; cdi-dev&lt;cdi-dev(a)lists.jboss.org&gt; >>> Sent: Friday, October 7, 2011 12:03 AM >>> Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) >>> >>> >>> I feel we need it too. I guess this goes without saying though. >>> >>> >>> >>> On Thu, Oct 6, 2011 at 2:51 PM, Pete Muir&lt;pmuir(a)redhat.com&gt; wrote: >>> >>> I've received a lot of feedback at JavaOne that XML config is something people want to see in the standard. So I would like to revisit this question. >>>> Feel free to discuss now, or I'll start with a proposal in a few weeks :-) >>>> >>>> >>>> On 5 Oct 2011, at 23:43, Mark Struberg wrote: >>>> >>>>> Fine thing. >>>>> >>>>> Although I see a few issues which I'd rather like to keep off core CDI as they are very easy to implement as portable Extensions (e.g. the XML config stuff CDI-123). >>>>> >>>>> We really must take care that we don't add things which bloats the CDI core spec with 20 pages which are hard to get right. >>>>> >>>>> >>>>> Instead we should really focus on things which are fundamental basics and thus cannot be done via a portable Extension. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: Pete Muir&lt;pmuir(a)redhat.com&gt; >>>>>> To: cdi-dev&lt;cdi-dev(a)lists.jboss.org&gt; >>>>>> Cc: >>>>>> Sent: Thursday, October 6, 2011 2:21 AM >>>>>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-) >>>>>> >>>>>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>> >>> >>> -- >>> Rick Hightower >>> (415) 968-9037 >>> Profile >>> >>> >>> >>> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev

I agree with you about most extensions. But XML is different. People expect XML config. Partly due to the pervasiveness of Spring et al. I agree the XML should look something like Seam XML. Anyway... just my 2 cents. On Fri, Oct 7, 2011 at 8:02 AM, Mark Struberg <struberg(a)yahoo.de&gt; wrote: Carlo, the argument is that CDI specifies portable extensions. Thus you don't need to specify any CDI-XML itself because the Seam-XML Extension is portable on any CDI container anyway. By giving the Hibernate example please remember how long it took to get a working JPA spec and that it is NOT hibernate which got specified. JPA is similar but not the exact same. LieGrue, strub ----- Original Message ----- > From: Carlo de Wolf <cdewolf(a)redhat.com&gt; > To: Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; > Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Friday, October 7, 2011 4:49 PM > Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) > > On 10/07/2011 09:17 AM, Stuart Douglas wrote: >> On 07/10/2011, at 6:13 PM, Mark Struberg wrote: >> >>> I basically share the sentiments Gavin posted on in.relation.to. We > could do it but we really should be picky and don't let the oldschool (call > it 'unsexy') EJB and EE like styled XML schema make it into the spec but > rather build on top of the namespace->package based syntax we had in the > original CDI draft. >>> >>> BUT: >>> >>> 1.) we need to be aware that XML schemas are NOT that easy to change > later! Thus if we see that we have forgotten something, then we are doomed for > the future... And this situation is highly likely imo since getting this part > right is not exactly easy. >>> >>> >>> 2.) writing a water-safe spec for this might get pretty hard. Expect to > add 20 more pages to our spec... >>> >>> >>> 3.) There is one de-facto standard for it already, which is seam-XML. > CODI nor any other CDI Extension project will introduce any similar stuff > because Seam-XML is working fine and has a perfectly business friendly license. > So I'm not sure which benefit writing it into the spec would bring. I see no > benefit over the current situation for CDI containers nor end-users. Au > contraire: if we hit an error in seam-xml, then it's easy to get this fixed > centrally. >>> >>> LieGrue, >>> strub >>> >>> >> I agree 100%. We already have a standards compliant and portable > implementation of XML configuration, thanks to CDI portable extensions. I really > don't see the benefit of writing this into the spec. >> >> Stuart > > While the implementation itself adheres to the CDI extension standard, > it in itself is not a standard. > > The question I have is, would users and vendors want to have CDI > extensions themselves be standardized? > > I think there is value in having some CDI extensions be certified. Not > just being a de-facto. > (Remember how Seam and Hibernate became de-jure.) > > Now this should in no way be attached to the CDI spec itself. Each > extension spec should have its independent lifecycle, so it can be > updated or deprecated at whim. > > I would even say that EJB 4 would make a nice case. > (Although calling it EJB 4 would be so wrong. ;-) ) > > Carlo > >>> >>>> ________________________________ >>>> From: Rick Hightower&lt;richardhightower(a)gmail.com&gt; >>>> To: Pete Muir&lt;pmuir(a)redhat.com&gt; >>>> Cc: Mark Struberg&lt;struberg(a)yahoo.de&gt;; > cdi-dev&lt;cdi-dev(a)lists.jboss.org&gt; >>>> Sent: Friday, October 7, 2011 12:03 AM >>>> Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) >>>> >>>> >>>> I feel we need it too. I guess this goes without saying though. >>>> >>>> >>>> >>>> On Thu, Oct 6, 2011 at 2:51 PM, Pete Muir&lt;pmuir(a)redhat.com&gt; > wrote: >>>> >>>> I've received a lot of feedback at JavaOne that XML config is > something people want to see in the standard. So I would like to revisit this > question. >>>>> Feel free to discuss now, or I'll start with a proposal in > a few weeks :-) >>>>> >>>>> >>>>> On 5 Oct 2011, at 23:43, Mark Struberg wrote: >>>>> >>>>>> Fine thing. >>>>>> >>>>>> Although I see a few issues which I'd rather like to > keep off core CDI as they are very easy to implement as portable Extensions > (e.g. the XML config stuff CDI-123). >>>>>> >>>>>> We really must take care that we don't add things which > bloats the CDI core spec with 20 pages which are hard to get right. >>>>>> >>>>>> >>>>>> Instead we should really focus on things which are > fundamental basics and thus cannot be done via a portable Extension. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: Pete Muir&lt;pmuir(a)redhat.com&gt; >>>>>>> To: cdi-dev&lt;cdi-dev(a)lists.jboss.org&gt; >>>>>>> Cc: >>>>>>> Sent: Thursday, October 6, 2011 2:21 AM >>>>>>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-) >>>>>>> >>>>>>> > http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>>> >>>> >>>> -- >>>> Rick Hightower >>>> (415) 968-9037 >>>> Profile >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev -- Rick Hightower (415) 968-9037 Profile

> Now this should in no way be attached to the CDI spec itself. Each > extension spec should have its independent lifecycle, so it can be > updated or deprecated at whim. I disagree here. I think XML config is fairly core to a DI model, and so belongs in CDI. However most other stuff does not belong in CDI. In fact some of the integrations specified in CDI 1.0 for Java EE probably belong elsewhere. We're starting in CDI 1.1 to move these out to a separate part of the spec doc, which may eventually lead to them becoming totally separate.

I think CDI has changed its purpose and scope enough that some of the intro material which made total sense when CDI was forming is now missing the mark. CDI sort of evolved what was possible. The intro is still talking about the CDI you are going to build and the problem it is trying to solve. CDI 1.1, problem has been solved well, and CDI redefined what was there. Anyway... the intro material does not match the current scope and where CDI is today. I think its important because some folks will never get past the intro... :) Don't want CDI to be pigeon holed into some role it has but it is so much more than that. It is more general purpose than that. I want to table this. I can offer some rewrites.. But wanted to throw this out there. On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev -- Rick Hightower (415) 968-9037 Profile

http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Word on the JavaOne street.... Section 1.2.3 *The Managed Beans specification defines the basic programming model for application components managed by the Java EE container.* *As defined by this specification, most Java classes, including all JavaBeans, are managed beans. This specification defines contextual lifecycle management and dependency injection as generic services applicable to all....* My understanding is that these are going away, and it is just CDI for Java EE 7 for JSF managed beans. Pretty sure I heard Arun Gupta say something like that in the tweetersphere during JavaOne..... If this is true, we should reword or delete this. Not sure exactly.. But it seems like something needs to be here to say that JSF Managed Beans are deprecated for CDI going forward (if that is in fact true). On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > > http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > -- *Rick Hightower* (415) 968-9037 Profile <http://www.google.com/profiles/RichardHightower>

________________________________ From: Rick Hightower <richardhightower(a)gmail.com&gt; To: Pete Muir <pmuir(a)redhat.com&gt; Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; Sent: Friday, October 14, 2011 2:51 AM Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) 1.2.6. Relationship to JSF JavaServer Faces is a web-tier presentation framework that provides a component model for graphical user interface components and an event-driven interaction model that binds user interface components to objects accessible via Unified EL. This specification allows any bean to be assigned a Unified EL name. Thus, a JSF application may take advantage of the sophisticated context and dependency injection model defined by this specification. Could this section really be called relationship to Servlets and JSP? Unified EL is not really part of JSF or JSP.  My recollection is that you can use CDI managed beans from Universal EL from JSPs. http://stackoverflow.com/questions/7385723/cdi-injection-in-a-jsp Thus, you could use it with any framework. Why is there no section on relationship with JSP and Servlets.... What we are really talking about is relationship with Unified EL.  Anyway... I find the CDI doc implies strong coupling with EJB and JSF that just does not exist in any version of CDI for the most part and certainly much less so with CDI 1.1. I would reword as follows.... (flawed but closer) 1.2.6. Relationship to JSF, Servlets and JSP If you use a framework like JavaServer Faces that uses the Unified EL, then it will work with this specification. This specification allows any bean to be assigned a Unified EL name. Thus, any technology that uses Unified EL, JSP, in a supported container can use beans managed by CDI. It is rough and perhaps not 100% accurate, but closer to what we have now. On Thu, Oct 13, 2011 at 4:55 PM, Rick Hightower <richardhightower(a)gmail.com&gt; wrote: Word on the JavaOne street.... > > > > >Section 1.2.3 > > >The Managed Beans specification defines the basic programming model for application components managed by the Java EE container. >As defined by this specification, most Java classes, including all JavaBeans, are managed beans. This specification defines contextual lifecycle management and dependency injection as generic services applicable to all.... > > >My understanding is that these are going away, and it is just CDI for Java EE 7 for JSF managed beans. >Pretty sure I heard Arun Gupta say something like that in the tweetersphere during JavaOne..... > > >If this is true, we should reword or delete this. Not sure exactly.. But it seems like something needs to be here to say that JSF Managed Beans are deprecated for CDI going forward (if that is in fact true). > > > > > > > >On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted >>_______________________________________________ >>cdi-dev mailing list &gt;&gt;cdi-dev(a)lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > > >-- >Rick Hightower >(415) 968-9037 >Profile  > > -- Rick Hightower (415) 968-9037 Profile  _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Word on the JavaOne street.... Section 1.2.3 The Managed Beans specification defines the basic programming model for application components managed by the Java EE container. As defined by this specification, most Java classes, including all JavaBeans, are managed beans. This specification defines contextual lifecycle management and dependency injection as generic services applicable to all.... My understanding is that these are going away, and it is just CDI for Java EE 7 for JSF managed beans. Pretty sure I heard Arun Gupta say something like that in the tweetersphere during JavaOne..... If this is true, we should reword or delete this. Not sure exactly.. But it seems like something needs to be here to say that JSF Managed Beans are deprecated for CDI going forward (if that is in fact true). On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev -- Rick Hightower (415) 968-9037 Profile

1.2.6. Relationship to JSF JavaServer Faces is a web-tier presentation framework that provides a component model for graphical user interface components and an event-driven interaction model that binds user interface components to objects accessible via Unified EL. This specification allows any bean to be assigned a Unified EL name. Thus, a JSF application may take advantage of the sophisticated context and dependency injection model defined by this specification. Could this section really be called relationship to Servlets and JSP? Unified EL is not really part of JSF or JSP. My recollection is that you can use CDI managed beans from Universal EL from JSPs. http://stackoverflow.com/questions/7385723/cdi-injection-in-a-jsp Thus, you could use it with any framework. Why is there no section on relationship with JSP and Servlets.... What we are really talking about is relationship with Unified EL. Anyway... I find the CDI doc implies strong coupling with EJB and JSF that just does not exist in any version of CDI for the most part and certainly much less so with CDI 1.1. I would reword as follows.... (flawed but closer) 1.2.6. Relationship to JSF, Servlets and JSP If you use a framework like JavaServer Faces that uses the Unified EL, then it will work with this specification. This specification allows any bean to be assigned a Unified EL name. Thus, any technology that uses Unified EL, JSP, in a supported container can use beans managed by CDI. It is rough and perhaps not 100% accurate, but closer to what we have now. On Thu, Oct 13, 2011 at 4:55 PM, Rick Hightower <richardhightower(a)gmail.com&gt; wrote: Word on the JavaOne street.... Section 1.2.3 The Managed Beans specification defines the basic programming model for application components managed by the Java EE container. As defined by this specification, most Java classes, including all JavaBeans, are managed beans. This specification defines contextual lifecycle management and dependency injection as generic services applicable to all.... My understanding is that these are going away, and it is just CDI for Java EE 7 for JSF managed beans. Pretty sure I heard Arun Gupta say something like that in the tweetersphere during JavaOne..... If this is true, we should reword or delete this. Not sure exactly.. But it seems like something needs to be here to say that JSF Managed Beans are deprecated for CDI going forward (if that is in fact true). On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev -- Rick Hightower (415) 968-9037 Profile -- Rick Hightower (415) 968-9037 Profile

a.)+1 UEL is nowadays not exclusively bound to JSF nor JSP anymore. And we must be careful with 'Servlets' and 'Servlet Specification' We all here know that JSF and JSP are also only 'Servlets' (as Wicket and Seam2 are, etc), but most people think about 'Servlets' only as their self-written stuff and often forget about the DefaultServlet and FacersSerlet also being Servlets of course. So we might go even further with the formulation? 1.2.6. Relationship to Servlet based Frameworks like JSF and JSP This specification allows any bean to be assigned a Unified-EL name. Thus, any technology that uses Unified EL - like JavaServerFaces or JavaServerPages - can use beans managed by CDI. The only part of CDI which is atm really bound to JSF is the @ConversationScoped. This needs some rework I guess. b.) CDI and EJB I think the old wording was a tribute to some political facts back then when the spec evolved. The option to make CDI also applicable for SE also was long time 'prohibited' ;) I think we got past this point since CDI-1.0 was a huge success so far. It's now clear that not EJB but parts which got extracted from EJB are really important. Do we already have an explicit wording that any CDI container need to fully implement the interceptors-spec which is 'part' of the EJB-3.1 JSR?

LieGrue, strub > ________________________________ > From: Rick Hightower <richardhightower(a)gmail.com&gt; > To: Pete Muir <pmuir(a)redhat.com&gt; > Cc: cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Friday, October 14, 2011 2:51 AM > Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-) > > > 1.2.6. Relationship to JSF > JavaServer Faces is a web-tier presentation framework that provides a component model for graphical user interface components and an event-driven interaction model that binds user interface components to objects accessible via Unified EL. > This specification allows any bean to be assigned a Unified EL name. Thus, a JSF application may take advantage of the sophisticated context and dependency injection model defined by this specification. > > > > Could this section really be called relationship to Servlets and JSP? > Unified EL is not really part of JSF or JSP. > > > My recollection is that you can use CDI managed beans from Universal EL from JSPs. > > > http://stackoverflow.com/questions/7385723/cdi-injection-in-a-jsp > > > Thus, you could use it with any framework. Why is there no section on relationship with JSP and Servlets.... > > > What we are really talking about is relationship with Unified EL. > > > Anyway... I find the CDI doc implies strong coupling with EJB and JSF that just does not exist in any version of CDI for the most part and certainly much less so with CDI 1.1. > > > I would reword as follows.... (flawed but closer) > > > 1.2.6. Relationship to JSF, Servlets and JSP > If you use a framework like JavaServer Faces that uses the Unified EL, then it will work with this specification. > This specification allows any bean to be assigned a Unified EL name. Thus, any technology that uses Unified EL, JSP, in a supported container can use beans managed by CDI. > > > It is rough and perhaps not 100% accurate, but closer to what we have now. > > > On Thu, Oct 13, 2011 at 4:55 PM, Rick Hightower <richardhightower(a)gmail.com&gt; wrote: > > Word on the JavaOne street.... >> >> >> >> >> Section 1.2.3 >> >> >> The Managed Beans specification defines the basic programming model for application components managed by the Java EE container. >> As defined by this specification, most Java classes, including all JavaBeans, are managed beans. This specification defines contextual lifecycle management and dependency injection as generic services applicable to all.... >> >> >> My understanding is that these are going away, and it is just CDI for Java EE 7 for JSF managed beans. >> Pretty sure I heard Arun Gupta say something like that in the tweetersphere during JavaOne..... >> >> >> If this is true, we should reword or delete this. Not sure exactly.. But it seems like something needs to be here to say that JSF Managed Beans are deprecated for CDI going forward (if that is in fact true). >> >> >> >> >> >> >> >> On Wed, Oct 5, 2011 at 5:21 PM, Pete Muir <pmuir(a)redhat.com&gt; wrote: >> >> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft... >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> >> >> >> >> -- >> Rick Hightower >> (415) 968-9037 >> Profile >> >> > > > > -- > Rick Hightower > (415) 968-9037 > Profile > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > >