Re: [cdi-dev] Cancelling today's meeting

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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; 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&gt; Subject: [cdi-dev] Cancelling today's meeting To: CDI Java EE Specification <cdi-dev(a)lists.jboss.org&gt; Message-ID: < CABu-YBSBVjJEyqJ37PexicXqsyc-eazMh4UMBDzfbstjoFVTWg(a)mail.gmail.com&gt; 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 **************************************