[JBoss JIRA] Issue Comment Edited: (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Marius Bogoevici edited comment on CDI-44 at 5/24/11 5:55 PM:
--------------------------------------------------------------
1. Use the same list of behavioural criteria as CDI-74 (which was created to cover interception)
2. Describe correct behaviour on self-invocation - and what is the effect of using proxies
was (Author: marius.bogoevici):
1. Use the same list of behavioural criteria as CDI-74 (which was created to cover interception)
2. Described self-invocation - when using a proxy
> 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: Marius Bogoevici
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Commented: (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Marius Bogoevici commented on CDI-44:
-------------------------------------
1. Use the same list of behavioural criteria as CDI-74 (which was created to cover interception)
2. Described self-invocation - when using a proxy
> 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: Marius Bogoevici
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Issue Comment Edited: (CDI-74) State explicitely that Decorators must be implemented using subclassing
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-74?page=com.atlassian.jira.plugin.sys... ]
Marius Bogoevici edited comment on CDI-74 at 5/24/11 5:52 PM:
--------------------------------------------------------------
Yes. We should describe the desired behaviour, not implementation. Any other observable traits besides the 3 that I mentioned?
was (Author: marius.bogoevici):
Yes. We should describe the desired behaviour, not implementation. Any other observable effects besides the 3 that I mentioned?
> 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: Marius Bogoevici
> Fix For: 1.1 (Proposed)
>
>
> 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:
> - fields on pseudo scoped managed beans are accessible
> - there's no restriction on what kinds of constructors may a managed bean have
> - no extra bean instances are created when a managed bean is created
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Commented: (CDI-74) State explicitely that Decorators must be implemented using subclassing
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-74?page=com.atlassian.jira.plugin.sys... ]
Marius Bogoevici commented on CDI-74:
-------------------------------------
Yes. We should describe the desired behaviour, not implementation. Any other observable effects besides the 3 that I mentioned?
> 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: Marius Bogoevici
> Fix For: 1.1 (Proposed)
>
>
> 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:
> - fields on pseudo scoped managed beans are accessible
> - there's no restriction on what kinds of constructors may a managed bean have
> - no extra bean instances are created when a managed bean is created
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
Shared dependent instance injection with circular reference through decorator
by Christian Bauer
Section 6.4 says about @Dependent that "No injected instance of the
bean is ever shared between multiple injection points."
The following test shows that the same instance of @Dependent Foo is
shared between multiple injection points, one in
TestDecoratorInjection, the other in BarDecorator.
import org.jboss.weld.environment.se.Weld;
import org.jboss.weld.environment.se.WeldContainer;
import javax.annotation.PostConstruct;
import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.enterprise.inject.Any;
import javax.inject.Inject;
import javax.inject.Singleton;
@Singleton
public class TestDecoratorInjection {
public static final Weld weld = new Weld();
public static final WeldContainer weldContainer = weld.initialize();
public static void main(final String[] args) throws Exception {
weldContainer.instance().select(TestDecoratorInjection.class).get().test();
}
@Inject
Foo foo; // Dependent instance of TestDecoratorInjection
void test() {
foo.test();
}
public static class Foo {
@PostConstruct
void init() {
System.out.println("INIT FOO");
}
@Inject
Bar bar; // Dependent instance of Foo
void print() {
System.out.println("FOO");
}
void test() {
bar.print();
}
}
public static interface Bar {
void print();
}
public static class BarImpl implements Bar {
@Override
public void print() {
System.out.println("Bar");
}
}
@Decorator
public static abstract class BarDecorator implements Bar {
@Inject
@Delegate
@Any
Bar delegate;
@Inject
Foo foo; // Dependent instance of what?!
@Override
public void print() {
foo.print();
}
}
}
15 years, 1 month
Should AnnotatedType also reflect inherited information?
by Mark Struberg
Hi!
I think the spec is not explicit on this question: Should the AnnotatedType delivered to the Extensions as parameter or via BeanManager#getAnnostatedType() also deliver information gathered from it's superclass hierarchy?
Sounds reasonable, but is nowhere explicitely defined. Thus I better ask ;)
txs and LieGrue,
strub
15 years, 1 month
Re: [cdi-dev] [weld-dev] Overly restrictive serialization requirements
by Pete Muir
Moving this to the CDI EG list.
On 24 May 2011, at 05:18, David Blevins wrote:
> I find CDI 1.0 section 6.6.4 and some of the TCK tests a little confusing. I know serialization like the back of my hand and much of that section does not line up with actual serialization requirements.
>
> The bottom line is that you can't statically check a class's serialization capabilities. Non-serializable object reference types are ok. Fields of java.lang.Object and other non-serialzable types are ok. The reference type does not need to be serializable, just the object at the other end of the reference needs to be serializable. Obviously you can't check that at deploy time, you need the instance. You can't even check it at runtime as there are callbacks in the Serialization API that allow the instance to control it's own serialization. If the class implements Serializable you just have to trust it will be when the time comes.
>
> Small example: https://gist.github.com/988120
>
> What's the point of mistrusting a class that claims to be serializable and adding CDI-specific restrictions on its fields, methods and constructor types?
>
>
> -David
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
15 years, 1 month
Fw: [weld-dev] Overly restrictive serialization requirements
by Mark Struberg
Hi David!
I'm forwarding this to the CID-EG list (weld-dev is only for JBoss Weld now).
LieGrue,
strub
--- On Tue, 5/24/11, David Blevins <david.blevins(a)gmail.com> wrote:
> From: David Blevins <david.blevins(a)gmail.com>
> Subject: [weld-dev] Overly restrictive serialization requirements
> To: weld-dev(a)lists.jboss.org
> Date: Tuesday, May 24, 2011, 4:18 AM
> I find CDI 1.0 section 6.6.4 and some
> of the TCK tests a little confusing. I know
> serialization like the back of my hand and much of that
> section does not line up with actual serialization
> requirements.
>
> The bottom line is that you can't statically check a
> class's serialization capabilities. Non-serializable
> object reference types are ok. Fields of
> java.lang.Object and other non-serialzable types are
> ok. The reference type does not need to be
> serializable, just the object at the other end of the
> reference needs to be serializable. Obviously you
> can't check that at deploy time, you need the
> instance. You can't even check it at runtime as there
> are callbacks in the Serialization API that allow the
> instance to control it's own serialization. If the
> class implements Serializable you just have to trust it will
> be when the time comes.
>
> Small example: https://gist.github.com/988120
>
> What's the point of mistrusting a class that claims to be
> serializable and adding CDI-specific restrictions on its
> fields, methods and constructor types?
>
>
> -David
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
15 years, 1 month
[JBoss JIRA] Commented: (CDI-1) Clarify how resource producer fields (for persistence contexts) interact with transaction propagation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/CDI-1?page=com.atlassian.jira.plugin.syst... ]
Stuart Douglas commented on CDI-1:
----------------------------------
The specification states the persistence context can be injected using @PersistenceContext however does explain exactly what sort of persistence context it is and how it interacts with PC propagation.
As the JPA states that only SFSB's can use a persistence context of type EXTENDED, the only valid type of persistence context is a transaction scoped em, which probably means the container must injection a dependent scoped proxy to a transaction scoped EM.
If this is the case, then does this entity manger follow the rules for persistence context propagation outline in JPA 7.6.3?
> Clarify how resource producer fields (for persistence contexts) interact with transaction propagation
> -----------------------------------------------------------------------------------------------------
>
> Key: CDI-1
> URL: https://issues.jboss.org/browse/CDI-1
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java EE integration
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month
[JBoss JIRA] Commented: (CDI-2) Interceptor bindings defined at method level should override those at the class level
by Marius Bogoevici (JIRA)
[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.syst... ]
Marius Bogoevici commented on CDI-2:
------------------------------------
Quite frankly, the nonbinding attributes part is gratuitous, but stating the obvious helped me clarify exactly what I meant :)
> Interceptor bindings defined at method level should override those at the class level
> -------------------------------------------------------------------------------------
>
> Key: CDI-2
> URL: https://issues.jboss.org/browse/CDI-2
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Marius Bogoevici
> Fix For: 1.1 (Proposed)
>
>
> Gavin said:
> "We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec."
> In section 9.5.2 of the spec:
> If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 1 month