[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-596:
-----------------------------
Fix Version/s: 2.0 (discussion)
> ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-596
> URL: https://issues.jboss.org/browse/CDI-596
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> Right now, it's not clear what happens if:
> * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed)
> * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}}
> We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone.
> This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-596?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-596:
-----------------------------
Summary: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used (was: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configureAnnotatedType() are used)
> ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configurator are used
> ------------------------------------------------------------------------------------------------
>
> Key: CDI-596
> URL: https://issues.jboss.org/browse/CDI-596
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Martin Kouba
>
> Right now, it's not clear what happens if:
> * a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed)
> * a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}}
> We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone.
> This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (CDI-596) ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configureAnnotatedType() are used
by Martin Kouba (JIRA)
Martin Kouba created CDI-596:
--------------------------------
Summary: ProcessAnnotatedType - clarify what happens if both setAnnotatedType() and configureAnnotatedType() are used
Key: CDI-596
URL: https://issues.jboss.org/browse/CDI-596
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Martin Kouba
Right now, it's not clear what happens if:
* a user first calls {{setAnnotatedType()}} and then obtains a reference to the configurator (note that the configurator should be initialized with the AT being processed)
* a user obtains a reference to a configurator and then invokes {{setAnnotatedType()}}
We could either forbid using both of these methods during one notification, or state that the "last one wins". I would rather go the first way as the second solution might be confusing and error-prone.
This applies to {{ProcessObserverMethod}}, {{ProcessBeanAttributes}} and {{ProcessInjectionPoint}} as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
PR review and Hangout meeting
by Antoine Sabot-Durand
Hi all,
During last meeting we discuss about making some meeting with hangout to be
more efficient with the current PR.
We could setup a meeting Tuesday evening to replace our IRC meeting (6:00
pm CEST) or any other day of the week (and later if necessary), but this
meeting will be useless if you don't have time to review the open PR.
So let me know if the slot is ok for you regarding availability and review
capacity before.
Antoine
10 years
Fwd: PR review and Hangout meeting
by Mark Paluch
---------- Forwarded message ---------
From: Antoine Sabot-Durand <antoine(a)sabot-durand.net>
Date: Mo., 4. Apr. 2016 um 18:36
Subject: Re: [cdi-dev] PR review and Hangout meeting
To: Mark Paluch <mpaluch(a)paluch.biz>
Oops sorry,
http://doodle.com/poll/bcc264akxiingc8z
Le lun. 4 avr. 2016 à 18:34, Mark Paluch <mpaluch(a)paluch.biz> a écrit :
> Hi Antoine,
>
> do you have a link to the Doodle?
>
> Thanks, Mark
>
>
> Am 04.04.2016 um 17:42 schrieb Antoine Sabot-Durand <
> antoine(a)sabot-durand.net>:
>
> Guys,
>
>
> I didn't got answer from my first mail. As I said I'm ok for Hangout
> meeting but only if the participant already start reviewing the open PR.
> So could we schedule such a meeting tomorrow or later this week.
> Please fill the following Doodle to give your best time slot for such a
> meeting.
>
> Antoine
>
> Le jeu. 31 mars 2016 à 16:38, Antoine Sabot-Durand <
> antoine(a)sabot-durand.net> a écrit :
>
>> Hi all,
>>
>> During last meeting we discuss about making some meeting with hangout to
>> be more efficient with the current PR.
>> We could setup a meeting Tuesday evening to replace our IRC meeting (6:00
>> pm CEST) or any other day of the week (and later if necessary), but this
>> meeting will be useless if you don't have time to review the open PR.
>> So let me know if the slot is ok for you regarding availability and
>> review capacity before.
>>
>> Antoine
>>
> _______________________________________________
>
>
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
>
10 years
[JBoss JIRA] (CDI-578) define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-578?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-578:
-----------------------------
Git Pull Request: https://github.com/cdi-spec/cdi/pull/272
> define behaviour of firing an event for an observer with transaction if the transaction is not open or marked rollback
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-578
> URL: https://issues.jboss.org/browse/CDI-578
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
>
> The original problem description can be found at https://issues.apache.org/jira/browse/OWB-1111
> If you have an observer
> {code}
> public void clearCacheAfterTx((a)Observes(during=TransactionPhase.AFTER_COMPLETION) ClearAfterTx payload) {...}
> {code}
> and you fire the event
> {code}
> clearCacheEvent.fire(new ClearCacheEvent());
> {code}
> In this case the behaviour when firing the event if the underlying transaction is already closed or rolled back is totally undefined. It might blow up or continue silently depending on the server.
> The problem is that you cannot enlisten a Synchronisation at the tx anymore.
> I think we should define/clarify how it should behave in the various phases.
> E.g. a during=AFTER_SUCCESS should NOT deliver the event immediately if the tx is already marked for rollback. But for AFTER_COMPLETION it might be perfectly fine.
> At the end we need a matrix of the the event phases + possible Exceptions
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (CDI-595) Clarify if it is possible to 'manually' use interceptor
by Thomas Andraschko (JIRA)
[ https://issues.jboss.org/browse/CDI-595?page=com.atlassian.jira.plugin.sy... ]
Thomas Andraschko commented on CDI-595:
---------------------------------------
+1
It would be great if we could enhance beanManager#resolveInterceptors to pass the bean.
Currently in DS we can only support interceptors with binding and not via @Interceptors as beanManager#resolveInterceptors can only be used with bindings.
It would be great if we could also enhance #resolveInceptors to be used with the interceptor class, too.
> Clarify if it is possible to 'manually' use interceptor
> -------------------------------------------------------
>
> Key: CDI-595
> URL: https://issues.jboss.org/browse/CDI-595
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Interceptors
> Affects Versions: 2.0-EDR1
> Reporter: Matej Novotny
>
> This issue was inspired by Deltapike issue ([DELTASPIKE-1060|https://issues.apache.org/jira/browse/DELTASPIKE-1060] and [DELTASPIKE-1108|https://issues.apache.org/jira/browse/DELTASPIKE-1108]).
> In the DS issue, the interceptor instance is created with {{new CreationalContext}} and injects an {{@Intercepted Bean}}.
> Later on, there is an attempt to manually call {{javax.enterprise.inject.spi.Interceptor.intercept(InterceptionType, T, InvocationContext)}}.
> This (obviously) fails, as the interceptor does not have a context (meaning a link to the bean it is supposed to intercept).
> Quoting the interceptors spec: "The lifecycle of an interceptor instance is the same as that of the target class instance with which it is associated."
> Therefore we might want to clarify whether creating interceptors in this way is valid at all.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
