clarify beans.xml handling in CDI Lite#591
Conversation
|
This is my proposal for jakartaee/cdi-tck#336. |
manovotn
left a comment
There was a problem hiding this comment.
I am fine specifying it like this so long as all interested parties acknowledge that while we spec it, we still cannot test it with TCKs.
| More kinds of bean archives exist in {cdi_full}. | ||
|
|
||
| Implementations that do not support {cdi_full} are required to ignore the content of the `beans.xml` file, except for the `bean-discovery-mode` attribute. | ||
| Implementations that do not support {cdi_full} are required to detect presence of an archive which contains a `beans.xml` file that has `bean-discovery-mode` attribute set to `all` and treat it as a deployment problem. |
There was a problem hiding this comment.
I am tempted to say we should add a commented out note about this assertion not being testable with a link to GH issue discussing that. Statement like this is bound to bounce back eventually and stir the same discussion.
There was a problem hiding this comment.
Or perhaps we could water it down (just to make it clearer it's not being asserted anywhere) and say:
Implementations that do not support {cdi_full} are encouraged/expected to...
There was a problem hiding this comment.
How about rewording something like:
Implementations that do not support {cdi_full} are required to detect presence of an archive which contains a beans.xml file that has bean-discovery-mode attribute. The attribute value neither none nor annotated can be treated as a deployment problem.
There was a problem hiding this comment.
During the CDI meeting we agreed that we want to state this as required even though it cannot currently be tested with TCKs.
With that in mind, I think we can go ahead and merge this PR in its current form.
No description provided.