-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a test of the beans.xml bean-discovery-mode attribute in Lite? #336
Comments
I am not sure that's testable universally for Lite and Full. But maybe I am just missing something. Here are my thoughts... There is 3 values it can have:
|
So we have this statement in the beans_4_0.xsd schema: <xs:attribute name="bean-discovery-mode" use="optional" default="annotated">
<xs:annotation>
<xs:documentation>
It is strongly recommended you use "annotated". This is now the default and it
is also the default as of 4.0 when an empty beans.xml file is seen. When running
in a CDI Lite environment, this is the only aspect of the beans.xml file that
is used.
If the bean discovery mode is "all", then all types in this
archive will be considered. If the bean discovery mode is
"annotated", then only those types with bean defining annotations will be
considered. If the bean discovery mode is "none", then no
types will be considered.
</xs:documentation> Should we just be saying that in a Lite environment this is not read? |
It needs to be read in Lite, but portable testing of the Hmm maybe we could have a test with 2 archives, both of them having |
Sure that's definitely possible but I didn't bring it up because I thought we don't want to do that for Lite. Apparently, I missed the fact that we already have lots of Lite tests with WAR.
I agree but we might want to change the wording in schema so that we mention |
+1 on adding tests to test
I am unclear about the |
No because that would create a non-portable behavior between Lite and Full (i.e. taking the same deployment to CDI Full would result in different behavior).
This is the tricky part - you cannot fail. Remember that all CDI Lite tests are executed by CDI Full implementations as well and those have to understand
This remains the same as it was up until now. |
I think we could possibly go one step further and define how exactly a bean discovery mode of "all" is non-portable. We currently say:
We could say something like:
That said, I don't think this is a big deal. |
We could, but it will, again, not be testable so I don't think it's worth the hassle. Alternatively we could just say that those impls are "encouraged" to treat it as deployment problem. The only way we could test these things would be a property indicating mode in which the TCK is executed and the assertions tuned to that. But I would be -100 on that one because it just makes TCK way less readable and the results dependent on setting some knobs.
@Ladicek I was thinking about this some more and we should try it but I am not sure its runnable everywhere. |
What is the Lite behaviour when it sees |
Weld is a CDI Full implementation. As such it understands
Please see the spec doc, 2.11.1. Bean archives. That is, to my knowledge, all the definition we have. |
It can't possibly be portable between across Lite-only and Full, so we have to say it's non-portable. What do you suggest we say on top of that?
Fair enough. I'm fine with keeping the situation as is, or we could have a group |
Crossed my mind as well but then it gets complicated for Lite implementation to tell which groups they need to execute and even worse for Full impls. |
The lite does not say anything about what other value except "annotated" behaves. Some runtime only suppots Lite only and I think the value of |
2.11.1. Bean archives, quoting:
|
Nope. This break portability from Lite to Full. With your suggestion, the deployment will work with CDI Lite, but will result in ambiguous resolution in CDI Full because
There is no telling, from inside a test, in which "mode" you run. CDI Full implementations do not have a concept of running in Lite mode either, they are just Full which means they by definition support everything Lite has. |
I understood the challenge. I think leaving the bean-discovery-mode with anything except
What is your proposal for maintaining portability from Lite to Full. I feel not specing the behaviour in Lite is even worse as the end users do not know what it will happen in lite when using
We need to agree on a behaviour and then add a test. I am not sure what is the speced behaviour for the |
I believe we have to distinguish 2 things:
I submitted jakartaee/cdi#591 with my proposal for dealing with item no 1. Feel free to comment there. When it comes to item no 2., we may have to admit that testing deployment problems is always hard and certain things may just be left untested. |
We already have all we need to maintain portability from Lite to Full. So long as the Lite application conforms to defined behavior, it is portable. The point of this issue is with mode
The inability of testing whatever behavior we agree on is the crux of this issue. And the reason why you cannot test it is precisely portability and the general ability to execute Lite under Full. Such test would inevitably have to expect contradicting results under Lite and Full.
Yes, that's good way of putting it, thank you. |
Are we validating the Lite implementations need to parse the beans.xml bean-discovery-mode attribute in Lite?
The text was updated successfully, but these errors were encountered: