[cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?

[arjan tijms (JIRA)]

    [ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153477#comment-13153477 ] 

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)