[cdi-dev] Cancelling today's meeting
Werner Keil
werner.keil at gmail.com
Tue Jan 26 05:26:16 EST 2016
Sorry to hear, get well soon,
Werner
On Tue, Jan 26, 2016 at 9:58 AM, <cdi-dev-request at lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev at 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 at lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner at 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.13575.1453739940912 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153253#comment-13153253
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.13628.1453740122448 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153258#comment-13153258
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.13652.1453740301155 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153262#comment-13153262
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15602.1453793460288 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153442#comment-13153442
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15671.1453794420341 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153451#comment-13153451
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15697.1453794840284 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://issues.jboss.org/browse/CDI-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153455#comment-13153455
> ]
>
> 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 at jboss.org>
> Subject: [cdi-dev] [JBoss JIRA] (CDI-579) Extension disqualifies a jar
> as 'implicit bean archive'?
> To: cdi-dev at lists.jboss.org
> Message-ID:
> <JIRA.12600902.1453672307000.15879.1453797720273 at Atlassian.JIRA>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> 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)
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 26 Jan 2016 08:58:06 +0000
> From: Antoine Sabot-Durand <antoine at sabot-durand.net>
> Subject: [cdi-dev] Cancelling today's meeting
> To: CDI Java EE Specification <cdi-dev at lists.jboss.org>
> Message-ID:
> <
> CABu-YBSBVjJEyqJ37PexicXqsyc-eazMh4UMBDzfbstjoFVTWg at 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/attachment.html
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at 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
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160126/a2532346/attachment-0001.html
More information about the cdi-dev
mailing list