[JBoss JIRA] (CDI-583) Observer resolution doesn't support Lambdas
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-583?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-583:
------------------------------------------
As discussed in WELD-2108, we should consider adding to the event types, the type defined at Event injection point to satisfy this use case.
But this should be done carefully to see if it doesn't add any regression to event behaviour.
> Observer resolution doesn't support Lambdas
> -------------------------------------------
>
> Key: CDI-583
> URL: https://issues.jboss.org/browse/CDI-583
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Events
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Antoine Sabot-Durand
>
> As stated in various discussion on JDK8, lambda expressions don't allow to retrieve parameter types by reflection.
> See:
> http://jdk8-dev.openjdk.java.narkive.com/bSPiKxap/jdk-8-lambda-reflection...
> As section 10.1 of the spec states:
> bq. The event types of the event include all superclasses and interfaces of the runtime class of the event object.
> In case of a lambda payload, observer resolution will fails when respecting the rule above since parameter type won't be retrieve from the lambda.
> For instance the following code
> {code}
> @Inject
> Event<Supplier<String>> stringSupplierEvent;
> ...
> Supplier<String> stringSupplier = () -> "Hello world";
> stringSupplierEvent.fire(stringSupplier);
> {code}
> will triggers an observer for {{Supplier}} but not an observer for {{Supplier<String>}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-583) Observer resolution doesn't support Lambdas
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-583:
----------------------------------------
Summary: Observer resolution doesn't support Lambdas
Key: CDI-583
URL: https://issues.jboss.org/browse/CDI-583
Project: CDI Specification Issues
Issue Type: Bug
Components: Events
Affects Versions: 2.0-EDR1, 1.2.Final
Reporter: Antoine Sabot-Durand
As stated in various discussion on JDK8, lambda expressions don't allow to retrieve parameter types by reflection.
See:
http://jdk8-dev.openjdk.java.narkive.com/bSPiKxap/jdk-8-lambda-reflection...
As section 10.1 of the spec states:
bq. The event types of the event include all superclasses and interfaces of the runtime class of the event object.
In case of a lambda payload, observer resolution will fails when respecting the rule above since parameter type won't be retrieve from the lambda.
For instance the following code
{code}
@Inject
Event<Supplier<String>> stringSupplierEvent;
...
Supplier<String> stringSupplier = () -> "Hello world";
stringSupplierEvent.fire(stringSupplier);
{code}
will triggers an observer for {{Supplier}} but not an observer for {{Supplier<String>}}.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-581:
----------------------------------------
Agree with Mark. Having anything not 100% reliable makes its usage impossible in practise.
> possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
> -------------------------------------------------------------------------------
>
> Key: CDI-581
> URL: https://issues.jboss.org/browse/CDI-581
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
>
> Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'.
> {quote}
> 12.4.3. Bean discovery
> * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event,
> {quote}
> But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean.
> I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean.
> * ProcessBean die _not_ have a veto(), PAT does have it.
> * PAT gets fired for all discovered classes, ProcessBean only for enabled ones.
> I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'?
> I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away.
> The same chicken-egg problem might apply to
> {quote}
> 11.5.9. ProcessBeanAttributes event
> The container must fire an event for each bean, interceptor or decorator deployed in a bean
> archive, before registering the Bean object."
> {quote}
> Reads "for every bean". But we don't have any beans yet. We can only make the Bean<T> after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right?
>
> What could work is roughly:
> * fire PAT for all detected classes
> * remove vetoed ones
> * fire PBA for all AnnotatedTypes
> * remove vetoed one
> * calculate disabled BeanAttributes (@Specializes rule for classes)
> * produce Beans
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg edited comment on CDI-581 at 2/12/16 5:51 AM:
------------------------------------------------------------
Thanks Martin. I also think that this solution will get 'close' but will not hit 100%. The question now is if we are happy with a 'somehow close' solution or we like to nail it down 100%?
In my personal opinion it's much preferable to have a clear rule and the processing is always strictly unidirectional and acyclic.
With having those 'cycles' in the processing we get 2 imo undesired results:
1.) It's pretty much almost unpredictable for a random joe user what will happen. That's imo a big drawback
2.) The rest of the cases which isn't solved by the complex cycling will end up being non-deterministic. Thus having an app which will work at one boot but fail (or just have a different behaviour) on another boot.
I really prefer to always send the ProcessBeanAttributes for all non-vetoed AnnotatedTypes and then have a clear sheet to determine which Bean<?> are not enabled and thus could get skipped. A PBA event for a later disabled bean is imo way better than missing a PBA event for a bean which is finally valid and in production.
was (Author: struberg):
Thanks Martin. I also think that this solution will get 'close' but will not hit 100%. The question now is if we are happy with a 'somehow close' solution or we like to nail it down 100%?
In my personal opinion it's much preferable to have a clear rule and the processing is always strictly unidirectional and acyclic.
With having those 'cycles' in the processing we get 2 imo undesired results:
1.) It's pretty much almost unpredictable for a random joe user what will happen. That's imo a big drawback
2.) We the rest of the cases which isn't solved by the complex cycling will end up being non-deterministic. Thus having an app which will work at one boot but fail (or just have a different behaviour) on another boot.
I really prefer to always send the ProcessBeanAttributes for all non-vetoed AnnotatedTypes and then have a clear sheet to determine which Bean<?> are not enabled and thus could get skipped. A PBA event for a later disabled bean is imo way better than missing a PBA event for a bean which is finally valid and in production.
> possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
> -------------------------------------------------------------------------------
>
> Key: CDI-581
> URL: https://issues.jboss.org/browse/CDI-581
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
>
> Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'.
> {quote}
> 12.4.3. Bean discovery
> * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event,
> {quote}
> But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean.
> I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean.
> * ProcessBean die _not_ have a veto(), PAT does have it.
> * PAT gets fired for all discovered classes, ProcessBean only for enabled ones.
> I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'?
> I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away.
> The same chicken-egg problem might apply to
> {quote}
> 11.5.9. ProcessBeanAttributes event
> The container must fire an event for each bean, interceptor or decorator deployed in a bean
> archive, before registering the Bean object."
> {quote}
> Reads "for every bean". But we don't have any beans yet. We can only make the Bean<T> after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right?
>
> What could work is roughly:
> * fire PAT for all detected classes
> * remove vetoed ones
> * fire PBA for all AnnotatedTypes
> * remove vetoed one
> * calculate disabled BeanAttributes (@Specializes rule for classes)
> * produce Beans
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-581:
-----------------------------------
Thanks Martin. I also think that this solution will get 'close' but will not hit 100%. The question now is if we are happy with a 'somehow close' solution or we like to nail it down 100%?
In my personal opinion it's much preferable to have a clear rule and the processing is always strictly unidirectional and acyclic.
With having those 'cycles' in the processing we get 2 imo undesired results:
1.) It's pretty much almost unpredictable for a random joe user what will happen. That's imo a big drawback
2.) We the rest of the cases which isn't solved by the complex cycling will end up being non-deterministic. Thus having an app which will work at one boot but fail (or just have a different behaviour) on another boot.
I really prefer to always send the ProcessBeanAttributes for all non-vetoed AnnotatedTypes and then have a clear sheet to determine which Bean<?> are not enabled and thus could get skipped. A PBA event for a later disabled bean is imo way better than missing a PBA event for a bean which is finally valid and in production.
> possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
> -------------------------------------------------------------------------------
>
> Key: CDI-581
> URL: https://issues.jboss.org/browse/CDI-581
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
>
> Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'.
> {quote}
> 12.4.3. Bean discovery
> * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event,
> {quote}
> But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean.
> I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean.
> * ProcessBean die _not_ have a veto(), PAT does have it.
> * PAT gets fired for all discovered classes, ProcessBean only for enabled ones.
> I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'?
> I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away.
> The same chicken-egg problem might apply to
> {quote}
> 11.5.9. ProcessBeanAttributes event
> The container must fire an event for each bean, interceptor or decorator deployed in a bean
> archive, before registering the Bean object."
> {quote}
> Reads "for every bean". But we don't have any beans yet. We can only make the Bean<T> after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right?
>
> What could work is roughly:
> * fire PAT for all detected classes
> * remove vetoed ones
> * fire PBA for all AnnotatedTypes
> * remove vetoed one
> * calculate disabled BeanAttributes (@Specializes rule for classes)
> * produce Beans
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-581?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-581:
----------------------------------
Implementation notes: In Weld, {{ProcessBeanAttributes}} delivery is divided in multiple phases. Let's assume we have the following classes:
{code:java}
@Specializes
class B extends A {
}
// This bean is specialized
class A {
}
{code}
The processing is roughly as follows:
# Fire PBA for all beans which are not specialized and are enabled in any bean archive (i.e. not an alternative, or selected alternative) -> fire event for B
# If any bean is vetoed within PBA delivery (e.g. during delivery for B), find alll specialized beans and repeat the process recursively (i.e. go to 1 for A)
Most likely it does not work 100% but it should work in most cases.
I agree that the wording _"if the class is an enabled bean"_ is not clear and should be clarified.
> possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
> -------------------------------------------------------------------------------
>
> Key: CDI-581
> URL: https://issues.jboss.org/browse/CDI-581
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
>
> Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'.
> {quote}
> 12.4.3. Bean discovery
> * if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event,
> {quote}
> But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean.
> I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean.
> * ProcessBean die _not_ have a veto(), PAT does have it.
> * PAT gets fired for all discovered classes, ProcessBean only for enabled ones.
> I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'?
> I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away.
> The same chicken-egg problem might apply to
> {quote}
> 11.5.9. ProcessBeanAttributes event
> The container must fire an event for each bean, interceptor or decorator deployed in a bean
> archive, before registering the Bean object."
> {quote}
> Reads "for every bean". But we don't have any beans yet. We can only make the Bean<T> after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right?
>
> What could work is roughly:
> * fire PAT for all detected classes
> * remove vetoed ones
> * fire PBA for all AnnotatedTypes
> * remove vetoed one
> * calculate disabled BeanAttributes (@Specializes rule for classes)
> * produce Beans
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-580:
------------------------------------------
I'd like to have it implicit. But [~mkouba] raised some reason I don't remember to have this pattern.
> Allow interceptors and decorators to be applied to the return value of a producer method
> ----------------------------------------------------------------------------------------
>
> Key: CDI-580
> URL: https://issues.jboss.org/browse/CDI-580
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0-EDR1
> Reporter: Mark Struberg
>
> Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods.
> if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object.
> We should explore ways to allow this somehow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-580:
----------------------------------------
Can't the disposal part be implicit? The container knows it destroys the produced instance and that it is an intercepted one so it should be able to destroy it alone, no?
> Allow interceptors and decorators to be applied to the return value of a producer method
> ----------------------------------------------------------------------------------------
>
> Key: CDI-580
> URL: https://issues.jboss.org/browse/CDI-580
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0-EDR1
> Reporter: Mark Struberg
>
> Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods.
> if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object.
> We should explore ways to allow this somehow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months
[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-580:
------------------------------------------
Or {{UnmanagedInstance}} plus interceptor and decorators. Delivered instances are not managed by the container.
Of course in the Producer use case, the result will be managed but because of {{@Produces}} not {{BeanInstanceProducer}}.
> Allow interceptors and decorators to be applied to the return value of a producer method
> ----------------------------------------------------------------------------------------
>
> Key: CDI-580
> URL: https://issues.jboss.org/browse/CDI-580
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0-EDR1
> Reporter: Mark Struberg
>
> Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods.
> if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object.
> We should explore ways to allow this somehow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 3 months