[cdi-dev] CDI 1.1 EDR1 posted :-)

[Pete Muir]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev