[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-584:
----------------------------------
I'm a big fan of defensive programming and my assumption is all the metadata exposed to the user should be immutable. This "temporary mutable thing" is a bad idea and might only bring confusion. Also I think it's not a clear API if an interface behaves differently in different situations.
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-585) Add the possibility to remove a bean in AfterBeanDiscovery event
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-585?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-585:
------------------------------------------
Yes there are probably limitation to take care of. This said, validation of the container comes just after and if you did a nasty thing you'll have a deployment error.
> Add the possibility to remove a bean in AfterBeanDiscovery event
> ----------------------------------------------------------------
>
> Key: CDI-585
> URL: https://issues.jboss.org/browse/CDI-585
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Antoine Sabot-Durand
>
> Right now, the last occasion to "veto" a bean is in {{ProcessBeanAttributes}}, but we sometimes need to have all the bean discovered to decide if a given Bean should be present or not.
> Sometimes we also need a way to decide lately for some bean properties, so it would be useful to remove the original bean and provide a custom one wrapping it in replacement.
> Adding the {{removeBean(Bean<?> bean)}} to {{AfterBeanDiscoveryEvent}} would be helpful to perform easily these use case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-585) Add the possibility to remove a bean in AfterBeanDiscovery event
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-585?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-585:
-----------------------------------
I like this idea, BUT we _really_ have to be careful with all the 'disabled beans' stuff. It is again a chicken-egg problem. If you remove a @Specializes bean for example, then you king of change the whole constellation...
> Add the possibility to remove a bean in AfterBeanDiscovery event
> ----------------------------------------------------------------
>
> Key: CDI-585
> URL: https://issues.jboss.org/browse/CDI-585
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.2.Final, 2.0-EDR1
> Reporter: Antoine Sabot-Durand
>
> Right now, the last occasion to "veto" a bean is in {{ProcessBeanAttributes}}, but we sometimes need to have all the bean discovered to decide if a given Bean should be present or not.
> Sometimes we also need a way to decide lately for some bean properties, so it would be useful to remove the original bean and provide a custom one wrapping it in replacement.
> Adding the {{removeBean(Bean<?> bean)}} to {{AfterBeanDiscoveryEvent}} would be helpful to perform easily these use case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-585) Add the possibility to remove a bean in AfterBeanDiscovery event
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-585:
----------------------------------------
Summary: Add the possibility to remove a bean in AfterBeanDiscovery event
Key: CDI-585
URL: https://issues.jboss.org/browse/CDI-585
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Portable Extensions
Affects Versions: 2.0-EDR1, 1.2.Final
Reporter: Antoine Sabot-Durand
Right now, the last occasion to "veto" a bean is in {{ProcessBeanAttributes}}, but we sometimes need to have all the bean discovered to decide if a given Bean should be present or not.
Sometimes we also need a way to decide lately for some bean properties, so it would be useful to remove the original bean and provide a custom one wrapping it in replacement.
Adding the {{removeBean(Bean<?> bean)}} to {{AfterBeanDiscoveryEvent}} would be helpful to perform easily these use case.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-584:
-------------------------------------
Description:
{{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
was:
{{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice.
The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each impl made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-584?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-584:
-------------------------------------
Description:
{{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice.
The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
was:
{{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set mutable in OWB and immutable in Weld.
As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice.
The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
> Clarification needed on Set mutability returned by SPI
> ------------------------------------------------------
>
> Key: CDI-584
> URL: https://issues.jboss.org/browse/CDI-584
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Reporter: Antoine Sabot-Durand
>
> {{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set is mutable in OWB and immutable in Weld.
> As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice.
> The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
> More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-584) Clarification needed on Set mutability returned by SPI
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-584:
----------------------------------------
Summary: Clarification needed on Set mutability returned by SPI
Key: CDI-584
URL: https://issues.jboss.org/browse/CDI-584
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Reporter: Antoine Sabot-Durand
{{ProcessBean}} lifecycle event could be the occasion to add new Injection point to an existing bean, but when you call {{ProcessBean#getBean()#getInjectionPoints()}} the returned set mutable in OWB and immutable in Weld.
As the spec doesn't precise if the Set should be mutable or not, each spec made its own choice.
The result is a lack of consistency between both impl and an interesting feature harder to do with Weld (work with AnnotatedType or create a custom bean to add injection point)
More generally we should clarify mutability of each Set returned in the SPI. And check if it wouldn't be better to add method to life cycle event to provide a "temporary" mutable set (i.e. {{ProcessBean#getInjectionPoints()}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-414:
------------------------------------------
bq.Not sure it is really worth all the hassle. At the end this feature is very rarely used.
It is not used since it's not possible today. It's a new feature proposal
bq. Of course it IS used and sometimes needed. But for those occasions there is the well-known pattern of simply using self-injection manually.
IMO Self-Injection is not a design pattern, it's a smelly trick introduced to EJB implementation limitation
The number of average joe who think that interceptor will be triggered from internal call is countless. Check on Stack Overflow
bq. PS: 'business method' is a well defined term in the EJB spec.
What's the interest of this remark? CDI is not EJB and had to give its own definition of "business method" since Interceptor spec doesn't.
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Fix For: 2.0 (discussion)
>
>
> Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.
> This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.
> {code}
> @Stateless
> public class Foo {
> @EJB
> private Foo self;
> // ...
> }
> {code}
> Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
> Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:
> {noformat}
> WELD-001443 Pseudo scoped bean has circular dependencies.
> {noformat}
> See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb
> Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.
> With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-414:
-----------------------------------
To further clarify what Jozef (assumingly) means: There are 2 technically possible ways
1.) split this out into 2 different chains
1.a.) a general interceptor proxy (as we have today) for all class level outside invocations
1.b.) an own subclassing proxy for all self interceptors. Maybe we even need an own subclass per interceptor.
2.) ThreadLocals to transport the info of a 'local' call. That totally trashes concurrency, and thus a -1 to require it
I also think that the self interception is _not_ a question for the whole proxy but rather for the interceptor itself? or even for the interceptor + the class?
You probably like to apply a generic log interceptor from 'outside' and just like to trigger the @Transactional for your locally invoked method?
Not sure it is really worth all the hassle. At the end this feature is _very_ rarely used. Of course it IS used and sometimes needed. But for those occasions there is the well-known pattern of simply using self-injection manually.
We would also need to take a very close look at @PostConstruct and @PreDestroy as those are per definition trigger different interceptor mechanics.
PS: 'business method' _is_ a well defined term in the EJB spec.
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Fix For: 2.0 (discussion)
>
>
> Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.
> This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.
> {code}
> @Stateless
> public class Foo {
> @EJB
> private Foo self;
> // ...
> }
> {code}
> Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
> Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:
> {noformat}
> WELD-001443 Pseudo scoped bean has circular dependencies.
> {noformat}
> See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb
> Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.
> With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months
[JBoss JIRA] (CDI-527) allow proxying of classes with non-private final methods
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-527?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-527:
------------------------------------------
This feature was voted by the EG on Feb 15th 2016, but a majority of users expressed preference for the introduction of a dedicated annotation to support this advanced feature.
{{@AllowProxy}} was the name proposed by [~struberg] but we could also find a less low level name based on Business Method concept. suggestion are welcome.
As we are about to introduce a new annotation related to proxy behavior, I thought interesting to think about using it for other requested feature. See for example my comment in [CDI-414|https://issues.jboss.org/browse/CDI-414?focusedCommentId=13164732...]
> allow proxying of classes with non-private final methods
> --------------------------------------------------------
>
> Key: CDI-527
> URL: https://issues.jboss.org/browse/CDI-527
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 (proposed)
>
>
> Currently we explicitly disallow proxying of classes with non-private final methods.
> EJB _does_ allow this. And there are a few final methods in the JDK and other libs. E.g. HashMap#initHashSeedAsNeeded. Currently we cannot have a producer method for it.
> We might rethink our decision and allow it. Probably with an own annotation like @AllowProxying which disables this check for certain cases (subclass managed-beans or producers).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 10 months