[cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict

[Matej Novotny (JIRA)]

    [ 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<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).

> 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)