[
https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
]
arjan tijms commented on CDI-579:
---------------------------------
{quote}This reminds me that maybe we should also consider some "unification" of
configuration on the spec level (might be useful for other parts of the spec).{quote}
Do you mean CDI specific configuration or platform wide configuration?
The Java EE configuration spec was supposed to handle that latter concern, but as we know
this effort was largely aborted.
Unification would absolutely be welcome still, as would be some guidance at the platform
level. E.g. here it's proposed to change behaviour and then provide a switch to
restore the old behaviour.
JSF 2.3 however takes the opposite way. Out of the box it's JSF 2.2, and you need to
set a series of switches to incrementally turn it into a JSF 2.3.
IMHO this is confusing. For some specs you need to set switches to go back to old
behaviour while for others you need to set switches to get new behaviour.
And as for the location of said switches, {{web.xml}} is the closest we have to a
universal location, but CDI extensions can't read that one. Some specs have a
programmatic API (like Servlet and JASPIC), but the API is totally different between
specs. And then some specs have a service loader based mechanism to provide raw deployment
descriptors programmatically (see e.g.
http://jdevelopment.nl/jsf-22/#533).
Finally there's a bunch of annotations, spread all throughout the specs with many
their own usage patterns.
If CDI adds its own configuration then, though very welcome, it would be yet another
location and method where and how things are configured.
Extension disqualifies a jar as 'implicit bean archive'?
--------------------------------------------------------
Key: CDI-579
URL:
https://issues.jboss.org/browse/CDI-579
Project: CDI Specification Issues
Issue Type: Bug
Reporter: Mark Struberg
Priority: Minor
The bean-discovery-wording is a bit odd.
This has been in since CDI-1.1
{code}
An archive which:
• contains a beans.xml file with the bean-discovery-mode of none, or,
• contains an extension and no beans.xml file is not a bean archive.
is not a bean archive.
{code}
That means even if you have an @ApplicationScoped MyService class in a jar which has a
single CDI Extension then this MyServices will *not* get picked up as CDI bean? At least
according to this wording?
Feels mega-weird to me and might conflict with the implicit beans archive definition a
few lines below.
I'm pretty sure in OWB we will pick those beans up. How does Weld behave?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)