[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-579:
----------------------------------------
[~struberg] removing the descriptor would work if extensions can be discovered thanks to that and activate CDI:
{code}
@CdiMeta // mark it as an extension used to define the module containing it, no need of META-INF/services/...
public class MyModuleMeta {
void init(@Observes MetaRegistration reg) {
reg.discoveryMode(...); // if conflict => fail, but it is unlikely respecting modulesMy
}
}
{code}
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-579:
-----------------------------------
[~rmannibucau] the explanation with the Extension manually registering beans rings a bell. Maybe we should let it as is.
It's easy enough to just add a beans.xml.
And to be honest: making beans.xml optional was imo a bit of a mistake as it will be required to indicate a version="2.0" anyway ;)
> 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)
10 years, 1 month
Re: [cdi-dev] Cancelling today's meeting
by Werner Keil
Sorry to hear, get well soon,
Werner
On Tue, Jan 26, 2016 at 9:58 AM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (Romain Manni-Bucau (JIRA))
> 2. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (Emily Jiang (JIRA))
> 3. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (Romain Manni-Bucau (JIRA))
> 4. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (Martin Kouba (JIRA))
> 5. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (Matej Novotny (JIRA))
> 6. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (Romain Manni-Bucau (JIRA))
> 7. [JBoss JIRA] (CDI-579) Extension disqualifies a jar as
> 'implicit bean archive'? (arjan tijms (JIRA))
> 8. Cancelling today's meeting (Antoine Sabot-Durand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 Jan 2016 11:39:00 -0500 (EST)
> From: "Romain Manni-Bucau (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.13575.1453739940912(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
> ]
>
> Romain Manni-Bucau commented on CDI-579:
> ----------------------------------------
>
> Agree but strongly think it is not used at all cause of the user
> experience it provides and the easiest way to fix this issue which is to go
> back on beans.xml structure - alternative is to add code to the extension
> which is not a real gain for users.
>
> > 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)
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 25 Jan 2016 11:42:02 -0500 (EST)
> From: "Emily Jiang (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.13628.1453740122448(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
> ]
>
> Emily Jiang commented on CDI-579:
> ---------------------------------
>
> disagree on just removing the sentence without any way to revert back to
> the old behavior.
>
> > 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)
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 25 Jan 2016 11:45:01 -0500 (EST)
> From: "Romain Manni-Bucau (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.13652.1453740301155(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
> ]
>
> Romain Manni-Bucau commented on CDI-579:
> ----------------------------------------
>
> [~emilyj] how many users application did you see relying on this?
> Encountered this issue 4 times and each time the fix has been the same
> whoever lead it. Changing something not used or wrong is fine, even for
> specs, it is done in most new versions actually.
>
> > 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)
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 26 Jan 2016 02:31:00 -0500 (EST)
> From: "Martin Kouba (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15602.1453793460288(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
> ]
>
> Martin Kouba commented on CDI-579:
> ----------------------------------
>
> bq. Emily Jiang how many users application did you see relying on this?
> Encountered this issue 4 times...
> We should definitely not rely on similar estimates. [~rmannibucau] do you
> really believe your experience is representing the whole CDI community and
> all use cases? I think we should find out why it was written this way
> (probably some compatibility issue) and then consider changing this and
> adding a config property to switch back to the old behaviour. 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).
>
>
> > 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)
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 26 Jan 2016 02:47:00 -0500 (EST)
> From: "Matej Novotny (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15671.1453794420341(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> 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)
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 26 Jan 2016 02:54:00 -0500 (EST)
> From: "Romain Manni-Bucau (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15697.1453794840284(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy...
> ]
>
> Romain Manni-Bucau commented on CDI-579:
> ----------------------------------------
>
> >From my understanding when I impl-ed it in TomEE it was for existing
> extension registering beans from jars without beans.xml. If these jars are
> now auto discovered the app can be broken.
>
> That said I still think it is rare enough - [~mkouba] I don't think my
> experience represents the whole CDi community but 1. nobody said me I was
> wrong cause they met another case until now , 2. we can get a polling as we
> did for @New.
>
> Just passively thinking it can be used and add a mess in the spec for that
> is not the best default IMO (feature flag are a headache most of the time
> for deployers/users so if we can avoid it it would be better. If we cant
> then fine to add a flag or a new API in extensions to activate annotated
> mode).
>
> > 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)
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 26 Jan 2016 03:42:00 -0500 (EST)
> From: "arjan tijms (JIRA)" <issues(a)jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev(a)lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15879.1453797720273(a)Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> 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)
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 26 Jan 2016 08:58:06 +0000
> From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Subject: [cdi-dev] Cancelling today's meeting
> To: CDI Java EE Specification <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <
> CABu-YBSBVjJEyqJ37PexicXqsyc-eazMh4UMBDzfbstjoFVTWg(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi guys,
>
> I'm sick today and I don't think I'll be able to attend our meeting.
>
> Sorry,
>
> Antoine
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160126/a012cf18/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 62, Issue 6
> **************************************
>
10 years, 1 month
Cancelling today's meeting
by Antoine Sabot-Durand
Hi guys,
I'm sick today and I don't think I'll be able to attend our meeting.
Sorry,
Antoine
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by arjan tijms (JIRA)
[ 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)
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-579:
----------------------------------------
>From my understanding when I impl-ed it in TomEE it was for existing extension registering beans from jars without beans.xml. If these jars are now auto discovered the app can be broken.
That said I still think it is rare enough - [~mkouba] I don't think my experience represents the whole CDi community but 1. nobody said me I was wrong cause they met another case until now , 2. we can get a polling as we did for @New.
Just passively thinking it can be used and add a mess in the spec for that is not the best default IMO (feature flag are a headache most of the time for deployers/users so if we can avoid it it would be better. If we cant then fine to add a flag or a new API in extensions to activate annotated mode).
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Matej Novotny (JIRA)
[ 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)
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-579:
----------------------------------
bq. Emily Jiang how many users application did you see relying on this? Encountered this issue 4 times...
We should definitely not rely on similar estimates. [~rmannibucau] do you really believe your experience is representing the whole CDI community and all use cases? I think we should find out why it was written this way (probably some compatibility issue) and then consider changing this and adding a config property to switch back to the old behaviour. 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).
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-579:
----------------------------------------
[~emilyj] how many users application did you see relying on this? Encountered this issue 4 times and each time the fix has been the same whoever lead it. Changing something not used or wrong is fine, even for specs, it is done in most new versions actually.
> 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)
10 years, 1 month
[JBoss JIRA] (CDI-579) Extension disqualifies a jar as 'implicit bean archive'?
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-579:
---------------------------------
disagree on just removing the sentence without any way to revert back to the old behavior.
> 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)
10 years, 1 month
