[
https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
]
Matej Novotny commented on CDI-579:
-----------------------------------
To toss my two cents in...
With implicit bean archives you can just play around and add beans with no beans.xml and
it will work. Then you add an extension and suddenly it stops being an archive. This I
consider weird. I believe we should change it, nevertheless Emily made a good point here.
We do not want to make a change and lose the backward compatibility, and there should be a
way to revert to original behavior.
Martin also hit the nerve here imo - the sentence is so weird it seems to be there on
purpose (e.g. the aforementioned compatibility issues?) and we should investigate it.
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)