Agreed.
I think here a key goal is not to stifle innovation, and with something like the XML there
is not consensus on how to do it, so best keep it as an extension for now. OTOH we want to
promote a well built, consistent platform with Java EE, so having good integrations with
Java EE technologies is a strong argument.
As has been alluded too, perhaps having some sub-groups or separate JSRs for CDI
extensions in the future would work well. Also I would like to see other specs (e.g. JMS
2.0) take on CDI integration as a goal and not require this all to be in the CDI spec.
However realistically this will be somewhat adhoc as it depends on the various priorities
of various JSRs...
On 1 May 2011, at 14:37, Mark Struberg wrote:
Actually I would go even further:
If there is a way to implement a feature in a portable extension, then there must be a
_very_ good argument to even think about moving it to the CDI core spec.
Imo the CDI spec itself should be as compact as possible. WDYT?
LieGrue,
strub
--- On Sun, 5/1/11, Pete Muir <pmuir(a)redhat.com> wrote:
> From: Pete Muir <pmuir(a)redhat.com>
> Subject: Re: [cdi-dev] [JBoss JIRA] Commented: (CDI-123) Using Seam XML extension for
CDI and Candi XML as a guide, let's add the ability to do XML config back into the
specification
> To: "Mark Struberg (JIRA)" <jira-events(a)lists.jboss.org>
> Cc: cdi-dev(a)lists.jboss.org
> Date: Sunday, May 1, 2011, 5:59 PM
> Mark you raise a really good point
> here which is that when considering a feature a big element
> of whether we should give it priority for adding to the spec
> is whether it is possible to do it in a totally portable
> fashion already in an extension. If it is, then it's
> priority must necessarily be lower.
>
> On 1 May 2011, at 13:47, Mark Struberg (JIRA) wrote:
>
>>
>> [
https://issues.jboss.org/browse/CDI-123?page=com.atlassian.jira.plugin.sy...
> ]
>>
>> Mark Struberg commented on CDI-123:
>> -----------------------------------
>>
>> Actually this has been in the spec originally and got
> dropped later.
>> There are multiple reasons for dropping it:
>>
>> a) it would bloat the spec (would take at least 10
> pages to define all that stuff unambiguous)
>>
>> b) back then there was a BIG discussion about the
> style. Some wanted it 'modern', others wanted it EJB like.
>>
>> c) Seam XML or any other configuration Extension is
> portable anyway.
>>
>> d) In a Cluster/Cloud environment, you maybe like to
> configure your beans via the Database? So we could not
> satisfy all the needs anyway.
>>
>>
>>> Using Seam XML extension for CDI and Candi XML as
> a guide, let's add the ability to do XML config back into
> the specification
>>>
>
-----------------------------------------------------------------------------------------------------------------------------
>>>
>>>
> Key: CDI-123
>>>
> URL:
https://issues.jboss.org/browse/CDI-123
>>> Project:
> CDI Specification Issues
>>> Issue Type:
> Feature Request
>>> Components:
> Concepts
>>>
> Reporter: Richard Hightower
>>> Fix For:
> TBD
>>>
>>>
>>> Using Seam's CDI XML extension for CDI and Candi
> XML as a guide, let's add the ability to do XML config back
> into the specification.
>>> Annotations and Alternatives should always be the
> first line of offense for doing injection, decoration and
> interception. However, there are times when you want to
> configure things that don't fit well into this model. This
> is also useful for testing.
>>> This is not to give up type safeness via
> annotations, but to have some additional flexibility.
>>
>> --
>> This message is automatically generated by JIRA.
>> For more information on JIRA, see:
http://www.atlassian.com/software/jira
>> _______________________________________________
>> 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
>