[
https://issues.jboss.org/browse/CDI-721?page=com.atlassian.jira.plugin.sy...
]
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)