CDI 1.1 EDR1 posted :-)

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

CDI 1.1 EDR1 posted :-)

Pete Muir
Administrator
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Mark Struberg
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 <[hidden email]>
> To: cdi-dev <[hidden email]>
> Cc:
> Sent: Thursday, October 6, 2011 2:21 AM
> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Pete Muir
Administrator
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 <[hidden email]>
>> To: cdi-dev <[hidden email]>
>> Cc:
>> Sent: Thursday, October 6, 2011 2:21 AM
>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>
>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
I feel we need it too. I guess this goes without saying though. 


On Thu, Oct 6, 2011 at 2:51 PM, Pete Muir <[hidden email]> 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 <[hidden email]>
>> To: cdi-dev <[hidden email]>
>> Cc:
>> Sent: Thursday, October 6, 2011 2:21 AM
>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>
>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Mark Struberg
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 <[hidden email]>
>To: Pete Muir <[hidden email]>
>Cc: Mark Struberg <[hidden email]>; cdi-dev <[hidden email]>
>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 <[hidden email]> 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 <[hidden email]>
>>>> To: cdi-dev <[hidden email]>
>>>> Cc:
>>>> Sent: Thursday, October 6, 2011 2:21 AM
>>>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>
>>>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>
>>
>>_______________________________________________
>>cdi-dev mailing list
>>[hidden email]
>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>
>
>
>--
>Rick Hightower
>(415) 968-9037
>Profile 
>
>
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Stuart Douglas

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

>
>
>> ________________________________
>> From: Rick Hightower <[hidden email]>
>> To: Pete Muir <[hidden email]>
>> Cc: Mark Struberg <[hidden email]>; cdi-dev <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>
>>>>> To: cdi-dev <[hidden email]>
>>>>> Cc:
>>>>> Sent: Thursday, October 6, 2011 2:21 AM
>>>>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>>
>>>>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>> _______________________________________________
>>>>> cdi-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>
>>
>>
>> --
>> Rick Hightower
>> (415) 968-9037
>> Profile
>>
>>
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Mark Struberg
In reply to this post by Mark Struberg
Oh I forgot about the update scenario.


Seam-XML can already be used for various Weld, OWB and CanDI installations out there.
If we write it into the CDI-1.1 spec, then users need to wait another 2++ years for making use of it.

So, of course we could do it - but I see no real benefit. If you name me some use cases which are _only_ doable by adding the XML config into the spec, then please tell me.


LieGrue,
strub



----- Original Message -----

> From: Mark Struberg <[hidden email]>
> To: Rick Hightower <[hidden email]>; Pete Muir <[hidden email]>
> Cc: cdi-dev <[hidden email]>
> 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 <[hidden email]>
>> To: Pete Muir <[hidden email]>
>> Cc: Mark Struberg <[hidden email]>; cdi-dev
> <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>
>>>>>  To: cdi-dev <[hidden email]>
>>>>>  Cc:
>>>>>  Sent: Thursday, October 6, 2011 2:21 AM
>>>>>  Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>>
>>>>>
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  [hidden email]
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>
>>
>>
>> --
>> Rick Hightower
>> (415) 968-9037
>> Profile 
>>
>>
>>
>>
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Carlo de Wolf
In reply to this post by Stuart Douglas
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<[hidden email]>
>>> To: Pete Muir<[hidden email]>
>>> Cc: Mark Struberg<[hidden email]>; cdi-dev<[hidden email]>
>>> 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<[hidden email]>  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<[hidden email]>
>>>>>> To: cdi-dev<[hidden email]>
>>>>>> Cc:
>>>>>> Sent: Thursday, October 6, 2011 2:21 AM
>>>>>> Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>>>
>>>>>> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>
>>>
>>> --
>>> Rick Hightower
>>> (415) 968-9037
>>> Profile
>>>
>>>
>>>
>>>
>> _______________________________________________
>> cdi-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> _______________________________________________
> cdi-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/cdi-dev

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Mark Struberg
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 <[hidden email]>
> To: Stuart Douglas <[hidden email]>
> Cc: Mark Struberg <[hidden email]>; cdi-dev <[hidden email]>
> 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<[hidden email]>
>>>>  To: Pete Muir<[hidden email]>
>>>>  Cc: Mark Struberg<[hidden email]>;
> cdi-dev<[hidden email]>
>>>>  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<[hidden email]
> 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<[hidden email]>
>>>>>>>  To: cdi-dev<[hidden email]>
>>>>>>>  Cc:
>>>>>>>  Sent: Thursday, October 6, 2011 2:21 AM
>>>>>>>  Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>>>>
>>>>>>>
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  [hidden email]
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  [hidden email]
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>
>>>>
>>>>  --
>>>>  Rick Hightower
>>>>  (415) 968-9037
>>>>  Profile
>>>>
>>>>
>>>>
>>>>
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  [hidden email]
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>  _______________________________________________
>>  cdi-dev mailing list
>>  [hidden email]
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
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 <[hidden email]> 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 <[hidden email]>
> To: Stuart Douglas <[hidden email]>
> Cc: Mark Struberg <[hidden email]>; cdi-dev <[hidden email]>
> 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<[hidden email]>
>>>>  To: Pete Muir<[hidden email]>
>>>>  Cc: Mark Struberg<[hidden email]>;
> cdi-dev<[hidden email]>
>>>>  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<[hidden email]
> 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<[hidden email]>
>>>>>>>  To: cdi-dev<[hidden email]>
>>>>>>>  Cc:
>>>>>>>  Sent: Thursday, October 6, 2011 2:21 AM
>>>>>>>  Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>>>>
>>>>>>>
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  [hidden email]
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  [hidden email]
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>
>>>>
>>>>  --
>>>>  Rick Hightower
>>>>  <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
>>>>  Profile
>>>>
>>>>
>>>>
>>>>
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  [hidden email]
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>  _______________________________________________
>>  cdi-dev mailing list
>>  [hidden email]
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Stuart Douglas
I think with this that there is also the risk of fragmenting the CDI XML configuration. If XML configuration does make it into the spec, and it is not 100% compatible with Seam XML, you may end up with a situations where some applications use the CDI XML and some are using Seam XML. A similar situation could result if the XML configuration in the spec does not include all the Seam XML features.

Stuart



On 08/10/2011, at 5:47 AM, Rick Hightower wrote:

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 <[hidden email]> 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 <[hidden email]>
> To: Stuart Douglas <[hidden email]>
> Cc: Mark Struberg <[hidden email]>; cdi-dev <[hidden email]>
> 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<[hidden email]>
>>>>  To: Pete Muir<[hidden email]>
>>>>  Cc: Mark Struberg<[hidden email]>;
> cdi-dev<[hidden email]>
>>>>  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<[hidden email]
> 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<[hidden email]>
>>>>>>>  To: cdi-dev<[hidden email]>
>>>>>>>  Cc:
>>>>>>>  Sent: Thursday, October 6, 2011 2:21 AM
>>>>>>>  Subject: [cdi-dev] CDI 1.1 EDR1 posted :-)
>>>>>>>
>>>>>>>
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  [hidden email]
>>>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>>>
>>>>>
>>>>>  _______________________________________________
>>>>>  cdi-dev mailing list
>>>>>  [hidden email]
>>>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>>
>>>>
>>>>  --
>>>>  Rick Hightower
>>>>  <a href="tel:%28415%29%20968-9037" value="+14159689037">(415) 968-9037
>>>>  Profile
>>>>
>>>>
>>>>
>>>>
>>>  _______________________________________________
>>>  cdi-dev mailing list
>>>  [hidden email]
>>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>>  _______________________________________________
>>  cdi-dev mailing list
>>  [hidden email]
>>  https://lists.jboss.org/mailman/listinfo/cdi-dev
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 



_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Pete Muir
Administrator
A number of these arguments are actually meta-arguments about whether specifying things is a good idea or not, which I would like to declare out of scope of the discussion about XML. Otherwise we'll never get anything done. On this basis I would strike these arguments from the discussion as out of scope:

* Stuart's fragmentation argument. This inevitably happens when something is specified, it is the process of standardization to take the best of what the industry has and standardize on it. [This is a challenge for the developers of Seam XML as they will need to provide some XSLT to transform from the legacy Seam Config to a standardized version.]
* Mark's update frequency argument. Again, this is always an issue with specifying too early.
* Mark's backwards compatibility argument, this is always a risk of standardization

Let me now try to tease apart some of the other discussions:

On 7 Oct 2011, at 00:13, 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.

100% agreed. When I discussed this with the Java EE leadership team, I told them that this group would still categorically prefer no XML config, to one that looked like the "traditional" Java EE syntax. That we would want something that completely adhered to the spirit and style of the original proposal. This original proposal would be our starting point.

> 2.) writing a water-safe spec for this might get pretty hard. Expect to add 20 more pages to our spec...  

I would propose we write this into a separate part of the spec, just as we propose to do when we split out the Java EE integrations. This should be relatively clean.

I agree the extra verbosity is annoying, but I don't personally think this is a blocker.

>
>
> 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.


Personally I see this as an argument that we are ready to write down a formal spec for this. The industry has adopted this one approach and is happy with it. But again, this is really a meta-argument about standardization


On 7 Oct 2011, at 07:49, Carlo de Wolf wrote:

> While the implementation itself adheres to the CDI extension standard,
> it in itself is not a standard.

Right. Users look to Java EE to provide an application development platform. They are happy to use add ons for non-core concerns. The feedback I'm getting is that XML config is still a core concern.

>
> 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.)

I would agree with this comment. In fact, it's coming true in Java EE 7 in many cases - JMS 2 has extensive CDI support, JSF 2.2 has added a lot more CDI support, EJB services are being made applicable to CDI beans, JPA is adding some CDI support (e.g. injection into Entity Listeners).

I don't believe that portable extensions fundamentally change the arguments for/against standardization. All they do is make the "playground" in which people experiment more useful. Whilst a de-facto standard offers users many benefits, it still does not offer true vendor-portability.

> 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 would even say that EJB 4 would make a nice case.
> (Although calling it EJB 4 would be so wrong. ;-) )

:-)

Practically, what does this mean?

First, I will post a poll to get community feedback on whether XML should be in the spec. I'll write a preamble, and run it by you all first to get your agreement it makes sense.

I would like us to explore an XML configuration for CDI. As a straw man I will write up a proposal based on Gavin's original text, and then ask Stuart to help me update it to include the changes he made for Seam XML. We can then discuss it. At this point, we can decide whether we feel strongly this should be kept out of spec?
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Carlo de Wolf
On 10/12/2011 10:14 PM, Pete Muir wrote:
>> 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.
>
Ah yes, I was generalizing a bit too much here.
Also I was unaware of the plug points of the core XML.

Kudos, that you can put a core concern in an extension. ;-)

Carlo
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
In reply to this post by Pete Muir
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 <[hidden email]> wrote:
http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Pete Muir
Administrator
I would be more than happy to accept rewrites here.

I think the best way is for you to offer a proposal and then we discuss it here...


On 13 Oct 2011, at 19:16, Rick Hightower <[hidden email]> wrote:

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 <[hidden email]> wrote:
http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
Ok...  I am going through the spec. with a fine tooth comb now. I will offer some proposals. 

On Thu, Oct 13, 2011 at 11:23 AM, Peter Muir <[hidden email]> wrote:
I would be more than happy to accept rewrites here.

I think the best way is for you to offer a proposal and then we discuss it here...


On 13 Oct 2011, at 19:16, Rick Hightower <[hidden email]> wrote:

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 <[hidden email][hidden email]> wrote:
http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
_______________________________________________
cdi-dev mailing list
[hidden email][hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
<a href="tel:%28415%29%20968-9037" value="+14159689037" target="_blank">(415) 968-9037
Profile 




--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
In reply to this post by Pete Muir
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 <[hidden email]> wrote:
http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
In reply to this post by Pete Muir

Basically if CDI does these....

•Split specification into core and Java EE integration
•Bootstrap support
•Java SE context definition

1, 1.1, and 1.2 need to be rewritten.

The spec CDI 1.0 started out very JSF and EJB centric. CDI is, and is becoming more so, more general. 



Then all of the intro material from 
On Thu, Oct 13, 2011 at 11:23 AM, Peter Muir <[hidden email]> wrote:
I would be more than happy to accept rewrites here.

I think the best way is for you to offer a proposal and then we discuss it here...


On 13 Oct 2011, at 19:16, Rick Hightower <[hidden email]> wrote:

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 <[hidden email][hidden email]> wrote:
http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
_______________________________________________
cdi-dev mailing list
[hidden email][hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev



--
Rick Hightower
<a href="tel:%28415%29%20968-9037" value="+14159689037" target="_blank">(415) 968-9037
Profile 




--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Rick Hightower
In reply to this post by Rick Hightower

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.


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 <[hidden email]> 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 <[hidden email]> wrote:



--
Rick Hightower
<a href="tel:%28415%29%20968-9037" value="+14159689037" target="_blank">(415) 968-9037
Profile 




--
Rick Hightower
(415) 968-9037
Profile 


_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
Reply | Threaded
Open this post in threaded view
|

Re: CDI 1.1 EDR1 posted :-)

Mark Struberg
In reply to this post by Rick Hightower
What do you exactly mean with JavaSE contexts?
Do you mean that we should _explicitely_ declare that @ApplicationScoped, @RequestScoped and @SessionScoped must be active by default in SE apps?


In OWB and CODI we we provide the same contexts for both SE and EE already. But their behaviour is slightly different.

This is really a big benefit not only for SE apps, but also when it comes to unit testing, as you don't need to boot a whole container. Arquillian is pretty fast already, but doing it 'native' is still 10 times faster.

In OWB/CODI we started have something like the following in our Extension which registers our scopes


if (projectStage = ProjectStage.UnitTest) {
  registerDummyScopes()...
} else {
  registerRealScopes();
}

where the dummy scopes are just dumb Maps per Thread.


And sometimes we just have a Context Facade which gets the 'real' context implementation as a

@Dependent MyContextImpl

bean. In codi-core-impl we just provide a pure SE only implementation, in codi-jsf12-impl we provide a


@Specializes @Dependent
Jsf12MyContextImpl extends MyContextImpl

and in codi-jsf20-impl an

@Specializes @Dependent
Jsf20MyContextImpl extends Jsf12MyContextImpl

This works pretty well because the context registration is only done in @Observes AfterBeanDiscovery, thus you can fully use CDI itself in the Contexts.

The only thing you must take care is that internally used Contexts got registered before your own. E.g. the CODI @RestScoped an @WindowScoped storage internally,
thus @WindowScoped must get registered upfront.


Means, technically it is easily doable, but it's some homework to do for Containers and Extensions.


LieGrue,
strub


>________________________________
>From: Rick Hightower <[hidden email]>
>To: Peter Muir <[hidden email]>
>Cc: cdi-dev <[hidden email]>
>Sent: Friday, October 14, 2011 2:24 AM
>Subject: Re: [cdi-dev] CDI 1.1 EDR1 posted :-)
>
>
>
>
>Basically if CDI does these....
>
>•Split specification into core and Java EE integration
>•Bootstrap support
>•Java SE context definition
>
>
>1, 1.1, and 1.2 need to be rewritten.
>
>
>The spec CDI 1.0 started out very JSF and EJB centric. CDI is, and is becoming more so, more general. 
>
>
>
>
>
>
>Then all of the intro material from 
>On Thu, Oct 13, 2011 at 11:23 AM, Peter Muir <[hidden email]> wrote:
>
>I would be more than happy to accept rewrites here.
>>
>>
>>I think the best way is for you to offer a proposal and then we discuss it here...
>>
>>
>>Thanks!
>>
>>--
>>Pete Muir
>>http://in.relation.to/Bloggers/Pete
>>
>>On 13 Oct 2011, at 19:16, Rick Hightower <[hidden email]> wrote:
>>
>>
>>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 <[hidden email]> wrote:
>>>
>>>http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>>_______________________________________________
>>>>cdi-dev mailing list
>>>>[hidden email]
>>>>https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>
>>>
>>>
>>>
>>>--
>>>Rick Hightower
>>>(415) 968-9037
>>>Profile 
>>>
>>>
>
>
>
>--
>Rick Hightower
>(415) 968-9037
>Profile 
>
>
>_______________________________________________
>cdi-dev mailing list
>[hidden email]
>https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
>

_______________________________________________
cdi-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/cdi-dev
12