1:43 a.m.
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>
To: cdi-dev <cdi-dev(a)lists.jboss.org>
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
4:51 p.m.
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>
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> 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
>
5:03 p.m.
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> 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>
>> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>> 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 <http://www.google.com/profiles/RichardHightower>
2:13 a.m.
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>
To: Pete Muir <pmuir(a)redhat.com>
Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org>
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> 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>
>>> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>>> 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
2:17 a.m.
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 <richardhightower(a)gmail.com>
> To: Pete Muir <pmuir(a)redhat.com>
> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org>
> 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> 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>
>>>> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> 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
9:49 a.m.
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<richardhightower(a)gmail.com>
>> To: Pete Muir<pmuir(a)redhat.com>
>> Cc: Mark Struberg<struberg(a)yahoo.de>;
cdi-dev<cdi-dev(a)lists.jboss.org>
>> 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> 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>
>>>>> To: cdi-dev<cdi-dev(a)lists.jboss.org>
>>>>> 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
10:02 a.m.
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>
To: Stuart Douglas <stuart.w.douglas(a)gmail.com>
Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org>
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<richardhightower(a)gmail.com>
>>> To: Pete Muir<pmuir(a)redhat.com>
>>> Cc: Mark Struberg<struberg(a)yahoo.de>;
cdi-dev<cdi-dev(a)lists.jboss.org>
>>> 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>
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>
>>>>>> To: cdi-dev<cdi-dev(a)lists.jboss.org>
>>>>>> 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
1:47 p.m.
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> 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>
> To: Stuart Douglas <stuart.w.douglas(a)gmail.com>
> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev
<cdi-dev(a)lists.jboss.org>
> 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<richardhightower(a)gmail.com>
>>>> To: Pete Muir<pmuir(a)redhat.com>
>>>> Cc: Mark Struberg<struberg(a)yahoo.de>;
> cdi-dev<cdi-dev(a)lists.jboss.org>
>>>> 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>
> 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>
>>>>>>> To: cdi-dev<cdi-dev(a)lists.jboss.org>
>>>>>>> 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 <http://www.google.com/profiles/RichardHightower>
5:04 a.m.
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 <struberg(a)yahoo.de> 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>
> To: Stuart Douglas <stuart.w.douglas(a)gmail.com>
> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev
<cdi-dev(a)lists.jboss.org>
> 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<richardhightower(a)gmail.com>
>>>> To: Pete Muir<pmuir(a)redhat.com>
>>>> Cc: Mark Struberg<struberg(a)yahoo.de>;
> cdi-dev<cdi-dev(a)lists.jboss.org>
>>>> 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>
> 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>
>>>>>>> To: cdi-dev<cdi-dev(a)lists.jboss.org>
>>>>>>> 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
3:14 p.m.
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?
7:16 a.m.
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
8:36 a.m.
I created the poll - http://bit.ly/vOWV8F - please vote and ask others to do so as well…
On 12 Oct 2011, at 21:14, Pete Muir wrote:
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
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
2:19 a.m.
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 <struberg(a)yahoo.de>
To: Rick Hightower <richardhightower(a)gmail.com>; Pete Muir
<pmuir(a)redhat.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
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>
> To: Pete Muir <pmuir(a)redhat.com>
> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev
<cdi-dev(a)lists.jboss.org>
> 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> 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>
>>>> To: cdi-dev <cdi-dev(a)lists.jboss.org>
>>>> 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
1:16 p.m.
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> 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>
1:23 p.m.
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 <richardhightower(a)gmail.com> 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 <pmuir(a)redhat.com> 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
2:48 p.m.
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 <pmuir(a)redhat.com> 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 <richardhightower(a)gmail.com>
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 < <pmuir(a)redhat.com>
pmuir(a)redhat.com> wrote:
>
>
<http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft...
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft...
> _______________________________________________
> cdi-dev mailing list
> <cdi-dev@lists.jboss.org>cdi-dev(a)lists.jboss.org
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
7:24 p.m.
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 <pmuir(a)redhat.com> 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 <richardhightower(a)gmail.com>
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 < <pmuir(a)redhat.com>
pmuir(a)redhat.com> wrote:
>
>
<http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft...
> http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraft...
> _______________________________________________
> cdi-dev mailing list
> <cdi-dev@lists.jboss.org>cdi-dev(a)lists.jboss.org
> <https://lists.jboss.org/mailman/listinfo/cdi-dev>
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
4:01 a.m.
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 <richardhightower(a)gmail.com>
To: Peter Muir <pmuir(a)redhat.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
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 <pmuir(a)redhat.com> 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 <richardhightower(a)gmail.com> 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 <pmuir(a)redhat.com> wrote:
>>
>>http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>>_______________________________________________
>>>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
11:30 a.m.
We discussed Java SE support extensively in the CDI panel at JavaOne. There was a strong
agreement that defining a Java SE mode would be an excellent thing to do. If we do that,
we need to define the contexts available, and their lifecycle.
I created https://issues.jboss.org/browse/CDI-174 to track this. Mark, could you add how
OWB works there?
On 14 Oct 2011, at 10:01, Mark Struberg wrote:
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 <richardhightower(a)gmail.com>
> To: Peter Muir <pmuir(a)redhat.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> 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 <pmuir(a)redhat.com> 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 <richardhightower(a)gmail.com>
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 <pmuir(a)redhat.com> 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
>
>
>
11:27 a.m.
Can you record this comment on https://issues.jboss.org/browse/CDI-160 for posterity.
On 14 Oct 2011, at 01:24, Rick Hightower wrote:
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 <pmuir(a)redhat.com> 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 <richardhightower(a)gmail.com> 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 <pmuir(a)redhat.com> 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
6:55 p.m.
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> 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>
7:51 p.m.
*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>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> 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>
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
4:22 a.m.
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>
To: Pete Muir <pmuir(a)redhat.com>
Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
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> 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> wrote:
>
>http://in.relation.to/Bloggers/ContextsAndDependencyInjection11EarlyDraftSubmitted
>>_______________________________________________
>>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
11:11 a.m.
Good points all. Idk answers to EJB questions. I understand the politics of
yore. I wasn't involved with CDI then. I did not even think you guys would
ever pull it off. Hats off to everyone who fought the fine fight. So history
and relationships to other specifications has changed. Its in Java best
interest for CDI to shed its JSF and EJB shackles. I like the direction
things are going a lot.
So not to belabor the points... but the intro needs to reflect where CDI is
now. Mostly to avoid confusion in the world of Java.
11:32 a.m.
On 14 Oct 2011, at 10:22, Mark Struberg wrote:
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?
It's not very explicit (we can make it so, add an issue). Interceptors is a totally
separate spec from EJB, but owned by the same EG.
LieGrue,
strub
> ________________________________
> From: Rick Hightower <richardhightower(a)gmail.com>
> To: Pete Muir <pmuir(a)redhat.com>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> 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>
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> 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
>
>
>
11:27 a.m.
File an issue, and create a pull request if you want :-)
On 14 Oct 2011, at 01:51, Rick Hightower wrote:
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>
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> 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
11:26 a.m.
I'll add this to the agenda for my integration call with the Java EE spec leads.
On 14 Oct 2011, at 00:55, Rick Hightower 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> 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
4805
days inactive
4825
days old
27 comments
6 participants
participants (6)
-
Carlo de Wolf -
Mark Struberg -
Pete Muir -
Peter Muir
-
Rick Hightower -
Stuart Douglas