[JBoss JIRA] (CDI-89) Add @Unwraps from Seam Solder
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-89?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-89:
------------------------------
This issue may be better considered as a way to let beans manage their own lifecycle.
> Add @Unwraps from Seam Solder
> ------------------------------
>
> Key: CDI-89
> URL: https://issues.jboss.org/browse/CDI-89
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 1.1 (Proposed)
>
>
> @Unwraps allows for an essentially stateless scope for producer methods and fields.
> At injection time a dependent scoped proxy is injected into the injection point. When a methods is invoked on this proxy it calls the corresponding @Unwraps methods to get the instance to invoke the method on.
> Because the proxy is @Dependent scoped, the @Unwraps method can inject the corresponding InjectionPoint.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
CDI 1.1 EG meeting, 18th Sept
by Pete Muir
Present
======
Pete Muir
Mark Struberg
Jozef Hartinger
Martin Kouba
Joe Bergmark
Jason Porter
Marius Bogoevici
JJ Snyder
Notes
====
Disabling Extensions
-----------------------------
* CDI-157
Mark and Jason outlined their proposal as described on the issue. Pete to write up.
Application managed contextual instance lifecycle
--------------------------------------------------------------------
* https://issues.jboss.org/browse/CDI-89
* https://issues.jboss.org/browse/CDI-139
Some beans want to manage their own lifecycle, and explicitly destroy an instance.
We discussed adding a destroy() method to an interface which extends Context, which custom contexts need to implement in order to support removing arbitrary instances. This forms an SPI.
We discussed that there should be an SPI for this, and proposed sharing a solution with CDI-139. We ran over all the possibilities we could come up with for identifying the bean to be destroyed, and discussed that either you get passed a dependent scoped instance or a proxy. In both cases, you can destroy the instance from just this info.
Pete to write up.
Proxies or subclassing for interceptors and decorators
-------------------------------------------------------------------------
Discussion on the list :-)
* CDI-6
* CDI-74
* CDI-44
all relate to this
Superclasses of decorators are decorated types
-----------------------------------------------------------------
* CDI-224
Discussed this, and realised that as the decorated types are a filter for what methods are decorated, allowing decoration of classes would mean that you could no longer use a shared base class for both the decorator and the bean. Also noted that this is not backwards compatible (for the reason just mentioned). Will reject this and see if there is a user outcry!
Alignment of terminology to bean name
-----------------------------------------------------
* CDI-250
EG happy with moving to bean name exclusively
Is ContextNotActiveException thrown when an event is delivered to an observer that is not active?
------------------------------------------------------------------------------------------------------------------------------------
* CDI-75
Mark argued that this isn't 100% clear either way - it's arguable both ways. All agreed that it shouldn't be thrown by default. Will clarify that it isn't thrown, and possibly add a new state in which it is thrown (e.g. Reception.Strict or something somewhat less horribly named ;-)
Require serializable Contextual and CreationalContext
--------------------------------------------------------------------------
* CDI-24
EG happy
Circular dependencies
--------------------------------
* CDI-77
Pete's proposal was to detect cycles at deployment, and error. Mark concerned about performance overhead, and proposed just detecting at runtime. All agreed it would be good to reword the spec to be less ambiguous (currently says "cycles do not occur for dependent beans" which is true, but confusing) and specify what happens when a cycle occurs (StackOverflowException at runtime or deployment error).
Portlet support
--------------------
* CDI-120
EG generally unhappy about adding portlet support at all, and would prefer this to be in another spec. Pete proposed a halfway house, that fits well with what EGs are active - putting the support in a separate document we distribute alongside the CDI spec, like EJB does with interceptors.
11 years, 8 months
[JBoss JIRA] (CDI-6) Clarify InjectionTarget method parameters
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ]
Pete Muir commented on CDI-6:
-----------------------------
Please review https://github.com/jboss/cdi/pull/117
> Clarify InjectionTarget method parameters
> -----------------------------------------
>
> Key: CDI-6
> URL: https://issues.jboss.org/browse/CDI-6
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Priority: Minor
> Fix For: 1.1.PRD
>
>
> For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object":
> - the product of the produce() method including interceptors and decorators -> a proxy
> - the target instance -> the object created by calling a constructor (no interception/decoration)
> Arguments for the first option
> - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy)
> - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance
> Arguments for the second option
> - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-6) Clarify InjectionTarget method parameters
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ]
Pete Muir updated CDI-6:
------------------------
Assignee: Pete Muir
> Clarify InjectionTarget method parameters
> -----------------------------------------
>
> Key: CDI-6
> URL: https://issues.jboss.org/browse/CDI-6
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Minor
> Fix For: 1.1.PRD
>
>
> For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object":
> - the product of the produce() method including interceptors and decorators -> a proxy
> - the target instance -> the object created by calling a constructor (no interception/decoration)
> Arguments for the first option
> - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy)
> - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance
> Arguments for the second option
> - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-6) Clarify InjectionTarget method parameters
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-6?page=com.atlassian.jira.plugin.syst... ]
Pete Muir updated CDI-6:
------------------------
Fix Version/s: 1.1.PRD
(was: 1.1 (Proposed))
> Clarify InjectionTarget method parameters
> -----------------------------------------
>
> Key: CDI-6
> URL: https://issues.jboss.org/browse/CDI-6
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Minor
> Fix For: 1.1.PRD
>
>
> For the inject() method, the spec says: "inject() performs dependency injection upon the given object". It is not clear to me what does the "given object" refer two. if the CDI implementation uses proxies to implement interceptors and decorators, I can see two candidates for "the given object":
> - the product of the produce() method including interceptors and decorators -> a proxy
> - the target instance -> the object created by calling a constructor (no interception/decoration)
> Arguments for the first option
> - Let's have and extension that adds additional dependency injection capabilities by providing a custom InjectionTarget implementation and wrapping default InjectionTarget instances with custom ones. The custom InjectionTarget implementation does the additional DI in the inject() method and delegates to the default InjectionTarget instance to finish the injection. This implementation needs a direct access to the target instance (it cannot access field values through a proxy)
> - Interceptor-like behavior - similarity to interceptors, where the InvocationContext.getTarget() returns the (non-intercepted) target instance
> Arguments for the second option
> - the contract of the produce() method says: "produce() calls the constructor annotated @Inject if it exists, or the constructor with no parameters otherwise, as defined in Section 5.5.1, "Injection using the bean constructor", and returns the resulting instance. If the class has inter- ceptors, produce() is responsible for building the interceptors and decorators of the instance." which means it returns an intercepted/decorated instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-44:
-------------------------
Fix Version/s: 1.1.PRD
(was: 1.1 (Proposed))
> Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
> -------------------------------------------------------------------------------------------------------------
>
> Key: CDI-44
> URL: https://issues.jboss.org/browse/CDI-44
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Fix For: 1.1.PRD
>
>
> When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not.
> When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-74) State explicitely that Decorators must be implemented using subclassing
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-74?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-74:
-------------------------
Assignee: Pete Muir
> State explicitely that Decorators must be implemented using subclassing
> -----------------------------------------------------------------------
>
> Key: CDI-74
> URL: https://issues.jboss.org/browse/CDI-74
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Marius Bogoevici
> Assignee: Pete Muir
> Fix For: 1.1.PRD
>
>
> Subclassing should be mandatory for Decorators of managed beans which are not session beans (no restrictions in the case of the latter).
> This ensures that:
> (1) fields on pseudo scoped managed beans are accessible
> (2) there's no restriction on what kinds of constructors may a managed bean have
> (3) no extra bean instances are created when a managed bean is created
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-74) State explicitely that Decorators must be implemented using subclassing
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-74?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-74:
-------------------------
Fix Version/s: 1.1.PRD
(was: 1.1 (Proposed))
> State explicitely that Decorators must be implemented using subclassing
> -----------------------------------------------------------------------
>
> Key: CDI-74
> URL: https://issues.jboss.org/browse/CDI-74
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Marius Bogoevici
> Assignee: Pete Muir
> Fix For: 1.1.PRD
>
>
> Subclassing should be mandatory for Decorators of managed beans which are not session beans (no restrictions in the case of the latter).
> This ensures that:
> (1) fields on pseudo scoped managed beans are accessible
> (2) there's no restriction on what kinds of constructors may a managed bean have
> (3) no extra bean instances are created when a managed bean is created
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-44:
------------------------------
Please review https://github.com/jboss/cdi/pull/117
> Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
> -------------------------------------------------------------------------------------------------------------
>
> Key: CDI-44
> URL: https://issues.jboss.org/browse/CDI-44
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 1.1 (Proposed)
>
>
> When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not.
> When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-44:
-------------------------
Assignee: Pete Muir
> Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
> -------------------------------------------------------------------------------------------------------------
>
> Key: CDI-44
> URL: https://issues.jboss.org/browse/CDI-44
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not.
> When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months