From issues at jboss.org Wed Jan 10 06:51:00 2018 From: issues at jboss.org (Emily Jiang (JIRA)) Date: Wed, 10 Jan 2018 06:51:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-720) http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd does not exist In-Reply-To: References: Message-ID: Emily Jiang created CDI-720: ------------------------------- Summary: http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd does not exist Key: CDI-720 URL: https://issues.jboss.org/browse/CDI-720 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 2.0 .Final Environment: n/a Reporter: Emily Jiang beans.xml version 2 has no corresponding xsd, which can be accessible online. http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd does not exist -- This message was sent by Atlassian JIRA (v7.5.0#75005) From EMIJIANG at uk.ibm.com Wed Jan 10 06:53:53 2018 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Wed, 10 Jan 2018 11:53:53 +0000 Subject: [cdi-dev] http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd does not exist Message-ID: I talked to Antoine regarding this issue, but it was still not resolved. I have now raised the following jira to report the nonexistence of beans_2_0.xsd. https://issues.jboss.org/browse/CDI-720 Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI & MicroProfile Development Lead MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN Phone: +44 (0)1962 816278 Internal: 246278 Email: emijiang at uk.ibm.com Lotus Notes: Emily Jiang/UK/IBM at IBMGB Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20180110/6496783d/attachment-0001.html From issues at jboss.org Wed Jan 24 16:01:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 24 Jan 2018 16:01:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: Mark Struberg created CDI-721: --------------------------------- Summary: configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict Key: CDI-721 URL: https://issues.jboss.org/browse/CDI-721 Project: CDI Specification Issues Issue Type: Bug Components: Portable Extensions Affects Versions: 2.0 .Final Reporter: Mark Struberg {noformat} Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. {noformat} This rule is way too strict without any real reason. Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. We should delete this sentence without any substitution. The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 25 03:07:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 25 Jan 2018 03:07:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523515#comment-13523515 ] Martin Kouba commented on CDI-721: ---------------------------------- Well, I don't think we should remove this restriction. The reason was to simplify the contract and avoid possible confusion (see also CDI-596). Note that the result of configurator should replace the original one at the end of the observer invocation (there is no terminal operation in configurator API). E.g. in this example: {code:java} void observePat(@Observes ProcessAnnotatedType event) { event.configureAnnotatedType().add(RequestScoped.Literal.INSTANCE); event.setAnnotatedType(new FooAnnotatedType()); } {code} The configurator must be discarded completely. So we would have to change the wording of {{ProcessAnnotatedType.configureAnnotatedType()}} too. Something like _"... configurator AnnotatedType will replace the original one at the end of the observer invocation or when setAnnotatedType() is called..."_. Anyway, I don't see a benefit in allowing both methods to be called within a single observer method invocation. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 25 04:04:01 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Thu, 25 Jan 2018 04:04:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523552#comment-13523552 ] Mark Struberg commented on CDI-721: ----------------------------------- The AT configurator will build the AT when the AT is needed the next time. That might be at the end of _all_ events get invoked (when the AT is further processed by the CDI runtime) or when getAnnotatedType() is invoked on the pat the next time. Technically it doesn't make any difference whether this happens in the next observer method or in the same one. The CDI container, or resp the ProcessAnnotatedType implementation, has to deal with it anyway. So this restriction technically makes no sense. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jan 25 04:10:00 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Thu, 25 Jan 2018 04:10:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523558#comment-13523558 ] Matej Novotny commented on CDI-721: ----------------------------------- To underline it, this is about invoking the {{set}} and {{configure}} methods _within one observer invocation_. Across multiple methods (be it in one or multiple extensions) you can do as you please even now. To me this restriction seems OK and I think we should not remove it. While the reason behind it might not be technical, it enforces clearer code. There is no reason known to me where you (*within one method*) need to start configuring the object (say AT for now) and then you suddenly change you mind and call the {{setAT}} method and replace it altogether. That means the previous configuration was a waste of time and resources because you just tossed it away. Not to mention it is easy to refactor your code not to invoke both methods and first check what is it you want to do with that given AT. Therefore most people who write 'sane code' would not even bump into this and the rest will at least realize they are doing some extraneous work. We have yet to see a case where this restriction would block user from achieving something. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jan 27 07:55:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Sat, 27 Jan 2018 07:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524924#comment-13524924 ] Mark Struberg commented on CDI-721: ----------------------------------- So it seems we all do agree that this restriction is technically not needed, right? And here is why I came across it: Customer wanted to extend his old code (using getAnnoatedType() + wrapping it + setAnnotatedType(wrappedAT)). Of course he want's to leverage CDI-2.0 configureAnnotatedType. But for performance reasons and ease of reproducibility (observer ordering) they only have 1 PAT observer where they simply call the old method and the new method. It's not always nonsense to mix those 2 approaches. Just because we didn't think about it doesn't mean we should forbid it! > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jan 28 17:17:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Sun, 28 Jan 2018 17:17:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524948#comment-13524948 ] Martin Kouba commented on CDI-721: ---------------------------------- Mark, I understand that you found a good use case where the current approach does not work. But configurators were not meant to replace {{setAnnotatedType()}} and to cover all possible use cases. A configurator instance is currently *scoped to a container lifecycle observer method invocation* and if we change this in CDI 2.x I think we would break backward compatibility. Also we would have to add some "terminal" operation to the configurator API so that it would be clear when a configurator result should be used to replace the original AT: {code:java} void observe(@Observes ProcessAnnotatedType event) { AnnotatedTypeConfigurator configurator = event.configureAnnotatedType().add(RequestScoped.Literal.INSTANCE); // At this time we cannot "terminate" the configurator! event.setAnnotatedType(...); configurator.methods().forEach(m -> m.add(Whatever.Literal.INSTANCE)); } {code} > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 09:25:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 29 Jan 2018 09:25:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525355#comment-13525355 ] Mark Struberg commented on CDI-721: ----------------------------------- At first I also thought that we would need such a terminal() method. But after further thinking about it my conclusion is that we do *not*! Or better we already have it: getAnnotatedType(). What if some extension calls setAnnotatedType multiple times? The last one wins! But if the Extension is well built (and not just random nonsense) then it will first get the previous AT via getAnnotatedType(). Then modify this information and use it for setAnnotatedType. Please chedk how we did it in OWB: https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/portable/events/ProcessAnnotatedTypeImpl.java#L72 > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 10:56:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 29 Jan 2018 10:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525447#comment-13525447 ] Romain Manni-Bucau commented on CDI-721: ---------------------------------------- Hi kind of agree with Mark. This is like a builder pattern based on immutability (like in JSON-P). It works well and nothing technically justifies to prevent it. It is beneficial for developers and users so we should support it IMHO. Romain > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 12:15:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 29 Jan 2018 12:15:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525486#comment-13525486 ] Martin Kouba commented on CDI-721: ---------------------------------- [~struberg] bq. ...we already have it: {{getAnnotatedType()}} This is not a "terminal" method. You don't even need to call it at all. See also the example in my previous comment - what happens with the configurator reference after I call {{setAnnotatedType()}}? bq. What if some extension calls setAnnotatedType multiple times? Yes, this is how it is defined. bq. But if the Extension is well built ... We cannot rely on this. bq. Please chedk how we did it in OWB... I will do. [~rmannibucau] bq. This is like a builder pattern based on immutability... It's actually not a builder, that's why we call it configurators... bq. It is beneficial for developers... This is disputable. If we don't cover all possible corner cases properly it could be even contra productive. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 13:06:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 29 Jan 2018 13:06:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525505#comment-13525505 ] Romain Manni-Bucau commented on CDI-721: ---------------------------------------- [~mkouba] well it is close enough of a builder pattern - in particular with its fluent API - to be perceived as such. We only miss getAnnotatedType() to be the build() method somehow. Also it is not that countra productive since it is just a clarification and not a change in the API as Mark explained. Said otherwise, it can already be in use. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 13:26:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Mon, 29 Jan 2018 13:26:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525507#comment-13525507 ] Mark Struberg commented on CDI-721: ----------------------------------- Btw, just to complete the picture: it works the same if someone _first_ uses setAnnotatedType() and only later uses configureAnnotatedType. In that case configureAnnotatedType will clear the fixed AT and create a Configurator based on this AT. So you don' loose any information, regardless how you mix them up. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 16:55:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Mon, 29 Jan 2018 16:55:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525555#comment-13525555 ] Martin Kouba commented on CDI-721: ---------------------------------- Ok, so I'll repeat once again: 1. {{getAnnotatedType()}} is not a "terminal" operation and cannot be used as a "build()" method 2. We're talking about the scope of a single container lifecycle method invocation 3. In the snippet below, what happens on the line with {{configurator.methods()}}? {code:java} void observe(@Observes ProcessAnnotatedType event) { AnnotatedTypeConfigurator configurator = event.configureAnnotatedType().add(RequestScoped.Literal.INSTANCE); event.setAnnotatedType(...); configurator.methods().forEach(m -> m.add(Whatever.Literal.INSTANCE)); } {code} > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jan 29 17:20:00 2018 From: issues at jboss.org (Romain Manni-Bucau (JIRA)) Date: Mon, 29 Jan 2018 17:20:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525559#comment-13525559 ] Romain Manni-Bucau commented on CDI-721: ---------------------------------------- If you call getAnnotatedType in your ... it is all good, otherwise failing is fine. This simple and easy to impl rule makes 1 true. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 03:33:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 30 Jan 2018 03:33:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525667#comment-13525667 ] Mark Struberg commented on CDI-721: ----------------------------------- [~mkouba] your sample above is exactly as the following: {code:java} void observe(@Observes ProcessAnnotatedType event) { event.setAnnotatedType(newAT_1); event.setAnnotatedType(newAT_2); configurator.methods().forEach(m -> m.add(Whatever.Literal.INSTANCE)); } {code} Whether this makes sense or not is TOTALLY up to what happens between those 2 setAnnotatedType calls. Maybe the user wants to *intentionally* replace newAT_1 later? How could you know? It is *not* upon us to judge whether that code makes sense or not - it is purely a matter of the business logic of that project! > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 04:12:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 30 Jan 2018 04:12:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525690#comment-13525690 ] Mark Struberg commented on CDI-721: ----------------------------------- Another observation > A configurator instance is currently scoped to a container lifecycle observer method invocation Can you please point me to the section where you did read this? I'm not able to find it > and if we change this in CDI 2.x I think we would break backward compatibility. No, we just remove a synthetic restriction. This would be perfectly backward compatible. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 04:28:00 2018 From: issues at jboss.org (Antoine Sabot-Durand (JIRA)) Date: Tue, 30 Jan 2018 04:28:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525699#comment-13525699 ] Antoine Sabot-Durand commented on CDI-721: ------------------------------------------ Discussion on this topic took place nearly 18 months ago and decision was made to go that way. Now that spec, TCK and API (including javadoc) are published, it is too late to ask for such a modification. BTW at this step even a typo in the spec couldn't be officially released without a MR, so I don't understand how you can imagine that such a modification can be performed. This said, I agree that giving the possibility to reuse an {{AnnotatedTypeConfigurator}} could be useful, but I disagree on mixing approach in a given {{ProcessAnnotatedType}} observer. Providing access to a reusable {{AnnotatedTypeConfigurator}} in future CDI version could make sense (if I remember we decided that it would be better to wait for user feedback to introduce such a feature). So I suggest that instead of asking non backward compatibility change, we start thinking of pros and cons and eventually means to give access to a part of configurator API from outside container events. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 04:32:01 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 30 Jan 2018 04:32:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525705#comment-13525705 ] Martin Kouba commented on CDI-721: ---------------------------------- WRT snippet - so you're saying that newAT_2 is the final value and configurator.methods() part is simply ignored? That's imho pretty confusing. bq. Can you please point me to the section where you did read this? 11.5.6. ProcessAnnotatedType event, _"configureAnnotatedType() returns an AnnotatedTypeConfigurator (as defined in AnnotatedTypeConfigurator SPI) initialized with the AnnotatedType processed by the event to easily configure the AnnotatedType *which will be used to replace the original one at the end of observer invocation*. The method always returns *the same* AnnotatedTypeConfigurator"_, but I agree that it's defined a little vaugely. In any case, we would have to change the wording about replacing the original AT at the end of observer invocation which is IMHO incompatible behavioral change. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 05:24:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Tue, 30 Jan 2018 05:24:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525747#comment-13525747 ] Mark Struberg commented on CDI-721: ----------------------------------- [~antoinesabot-durand] the intention is to get this done for the next MR indeed! And again: this is *not* a backward incompatible change! [~mkouba] As noted before: "observer invocation" is highly ambiguous. It might be interpreted as "ObserverMethod invocation" but also as "em.fire()". And no, it's no change in behaviour as the internas are not visible from outside anyway > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 05:47:00 2018 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Tue, 30 Jan 2018 05:47:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525768#comment-13525768 ] Martin Kouba commented on CDI-721: ---------------------------------- bq. "observer invocation" is highly ambiguous. It might be interpreted as "ObserverMethod invocation" but also as "em.fire()" [~struberg] I don't think so. "observer invocation" != "event.fire()", that would be "observer notification", at least from the spec POV - see also 10.5. Observer notification. I insist that this is a backward incompatible change. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jan 30 10:03:01 2018 From: issues at jboss.org (Matej Novotny (JIRA)) Date: Tue, 30 Jan 2018 10:03:01 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526037#comment-13526037 ] Matej Novotny commented on CDI-721: ----------------------------------- bq. ... "observer invocation" is highly ambiguous.... Not really unless you are looking for a way to bend it on purpose. And we also agreed on that wording and it's meaning back there and from what I recall, there were quite long discussions on the CDI-558 PR(s). None of those discussions was concerned about the ambiguity of this observer statement. bq. And again: this is not a backward incompatible change! And again I beg to differ. Especially since we already have a [TCK test|https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/tests/extensions/configurators/invalid/ConfiguratorAndSetMethodTest.java] verifying that this exact behaviour doesn't work. This test was also recently slightly reworked on your own request from which I judge you didn't have a problem with this behaviour. This is basically a 180? turn; going from _this must not work_ to _this can work just fine_ - this discussion probably should have happened a year and half ago. Last but not least - Martin's question was neatly avoided, so I will just go ahead and repeat that: (NOTE: it isn't the same as Mark's code below, this one is obtaining the configurator twice which is what disputes spec wording) bq. 3. In the snippet below, what happens on the line with configurator.methods()? {code} void observe(@Observes ProcessAnnotatedType event) { AnnotatedTypeConfigurator configurator = event.configureAnnotatedType().add(RequestScoped.Literal.INSTANCE); event.setAnnotatedType(...); configurator.methods().forEach(m -> m.add(Whatever.Literal.INSTANCE)); } {code} With current spec wording, namely the part that says that no matter how many times you obtain configurator it will always be the same - it breaks the compatibility yet again. Two things can happen; either you return configurator or the newly set AT (which violets current wording and hence backward compat) or you return the previous one overriding the AT yet again (which is bewildering). > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jan 31 02:56:00 2018 From: issues at jboss.org (Mark Struberg (JIRA)) Date: Wed, 31 Jan 2018 02:56:00 -0500 (EST) Subject: [cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526408#comment-13526408 ] Mark Struberg commented on CDI-721: ----------------------------------- [~manovotn] In OWB we still return the same instance of the configurator. This is perfectly solvable. And no, I didn't avoid to answer Martins question. Whether a user manipulates the AnnotatedType via setAnnotatedType or configureAnnotatedType MUST make absolutely no difference. By acknowledging that we can further safely assume that both ways should be interchangeably from a user pov. As shown with the setAnnotatedType: whatever happens as last step will be the full and only truth. Any AT change inbetween - which is not being wrapped - will be ultimately lost. That's the same with setAnnotatedType and I see no way nor reason to change this for configureAnnotatedType. Mathematically speaking: if B is an inclusive superset of A then we can widen our solution from A to B and ensure 100% backward compatibility. > configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict > ---------------------------------------------------------------------------- > > Key: CDI-721 > URL: https://issues.jboss.org/browse/CDI-721 > Project: CDI Specification Issues > Issue Type: Bug > Components: Portable Extensions > Affects Versions: 2.0 .Final > Reporter: Mark Struberg > > {noformat} > Any observer of this event is permitted to wrap and/or replace the AnnotatedType by calling either setAnnotatedType() or configureAnnotatedType(). If both methods are called within an observer notification an IllegalStateException is thrown. > {noformat} > This rule is way too strict without any real reason. > Any CDI container must support that both methods are being called on the same event payload anyway. Because we did not forbid that observerMethod1 invokes setAnnotatedType and observerMethod2 uses configureAnnoatedType. And that's good that way, otherwise the pluggability would be lost. > We should delete this sentence without any substitution. > The same applies to similar configurator methods like configureBeanAttributes, etc. -- This message was sent by Atlassian JIRA (v7.5.0#75005)