- 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
* Mark's update frequency argument. Again, this is always an issue with specifying
* 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
> 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
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