[
https://issues.jboss.org/browse/CDI-609?page=com.atlassian.jira.plugin.sy...
]
Tomas Remes commented on CDI-609:
---------------------------------
While I am implementing TCK tests I am starting to dislike those read methods at all TBH.
They appear to me as a nasty workaround (I don't like the fact that when I want to
create fresh new observer method I need to read some existing. It doesn't really make
sense to me) . I would really rather go with something like
https://github.com/tremes/cdi/commit/6ebc86ad3fdd34a491c53dc90628fbfecbae.... It's
much cleaner IMHO - just allow configuration (like qualifiers, reception, isAsync etc.)
within {{ProcessObserverMethod}} but things like setting observedType and beanClass allow
only within {{AfterBeanDiscovery}} when you really want to add new observer method. With
this you can do
https://gist.github.com/tremes/84c825a62cd3392c124814d036ee1239.
Clarify behaviour of ObserverMethodConfigurator<T> read
-------------------------------------------------------
Key: CDI-609
URL:
https://issues.jboss.org/browse/CDI-609
Project: CDI Specification Issues
Issue Type: Clarification
Affects Versions: 2.0-EDR2
Reporter: Tomas Remes
It's not clear what should happen in case if you are using ObserverMethodConfigurator
and attempting to read from a method ({{Method}}, {{AnnotatedMethod}}) which doesn't
have any parameter annotated @Observes. E.g something like this in ABD lifecycle event
("observesMelon" doesn't have any @Observes):
{code}
Method melonMethod = FruitObserver.class.getMethod("observesMelon",
Melon.class);
abd.addObserverMethod().read(melonMethod)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)