[ https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.sy... ] 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/o...] 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<Foo> event) { AnnotatedTypeConfigurator<Foo> 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). -- This message was sent by Atlassian JIRA (v7.5.0#75005)