[cdi-dev] [JBoss JIRA] (CDI-721) configureAnnotatedType vs setAnnotatedType restrition is unecessarily strict
Romain Manni-Bucau (JIRA)
issues at jboss.org
Mon Jan 29 13:06:00 EST 2018
[ 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)
More information about the cdi-dev
mailing list