9:01 a.m.
Comment inline.
T.
----- Original Message -----
From: "Antoine Sabot-Durand" <antoine(a)sabot-durand.net>
To: "Martin Kouba" <mkouba(a)redhat.com>
Cc: "cdi-dev" <cdi-dev(a)lists.jboss.org>
Sent: Friday, October 21, 2016 3:45:24 PM
Subject: Re: [cdi-dev] beans.xml quiz for Friday afternoon
> Usually I like quizzes, but this one is a bit harsh for a Friday
;).
> Since the spec doesn’t say anything about xml validation, I don’t
think we can take it into consideration for container behaviour.
Le 21 oct. 2016 à 15:23, Martin Kouba <mkouba(a)redhat.com> a
écrit :
Hi all,
today I struggled with weird beans.xml parsing problems and I found out
that this part of CDI might deserve some clarification. Below are few
examples. And not all of them have obvious interpretation.
Also note that the spec still contains invalid beans.xml snippets (see
also CDI-449).
> Do you mean, there are still invalid snipers after Tomas PR ?
1. empty beans.xml marker file
- spec VALID, bean-discovey-mode="ALL"
- XSD validation not needed
2. <beans/>
- spec VALID, bean-discovey-mode="ALL"
- XSD validation not possible
3. <beans xmlns="http://java.sun.com/xml/ns/javaee">
- spec VALID, Java EE 6 namespace, ie. CDI 1.0, bean-discovey-mode="ALL"
- XSD validation OK (against beans_1_0.xsd)
4. <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
- spec VALID
- XSD validation ERROR - Java EE 7 namespace, i.e. CDI 1.1+ and
bean-discovey-mode attribute is required
- note that version is defaulted to "1.1" (and e.g. SAXParser fills this
value automatically)
- what's the correct bean-discovey-mode? => I would expect ANNOTATED
because we're in EE 7 and it's the default bean discovery mode
- bean-discovey-mode attribute is required, not defaulted
- current Weld behavior: ALL
> As I said in introduction I don’t think we can take xsd into
consideration to decide container behaviour.
> So IMO here Weld behaviour is the expected one:
> "A bean archive which contains a beans.xml file with no
version has a default bean discovery mode of all"
That was my reasoning as well but note that when you specify beans_1_1.xsd then there is
_always_ version 1.1 as Martin pointed out.
5. <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
version="1.1">
- spec INVALID, "A bean archive which contains a beans.xml file with
version 1.1 (or later) must specify the bean-discovey-mode attribute.
The default value for the attribute is annotated."
- XSD validation ERROR, bean-discovey-mode attribute is required
- what's the correct bean-discovey-mode? => I would expect ANNOTATED
- current Weld behavior: ALL
> IMO, deployment should fail or we should rephrase the spec
(backward compatibility?)
6. <beans version="1.1">
- spec INVALID, the same as above
- XSD validation not possible
- what's the correct bean-discovey-mode? => I would expect ANNOTATED
- current Weld behavior: ALL
> Same as 5 for me
7. <beans version="1.1" bean-discovery-mode="annotated">
- spec VALID, bean-discovey-mode="ANNOTATED"
- XSD validation not possible
> NP
8. <beans version="1.1"
bean-discovery-mode="all"
xmlns="http://xmlns.jcp.org/xml/ns/javaee">
- spec VALID, bean-discovey-mode="ALL"
- XSD VALID
We may consider adding default value for bean-discovey-mode, and maybe
rewording the spec text. But I'm no XML guru so maybe I'm missing something.
> Again we don’t have any mention of valid XML file (regarding XSD)
in the spec, so there might be a lot of broken beans.xml file around. Making this straight
could break these apps.
We don't but we have default version="1.1" in beans_1_1.xsd which makes the
situation little bit more complicated. Otherwise I agree.
> wdyt ?
Thanks,
Martin
Antoine
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the code under the
Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
ideas provided on this list, the provider waives all patent and other intellectual
property rights inherent in such information.
--
Tomas Remes