[JBoss JIRA] Created: (CDI-128) We need a CDIInvocationContext which provides a getAnnotated
by Richard Hightower (JIRA)
We need a CDIInvocationContext which provides a getAnnotated
------------------------------------------------------------
Key: CDI-128
URL: https://issues.jboss.org/browse/CDI-128
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Richard Hightower
The issues with InvocationContext is it was designed before CDI as part of EJB 3. In CDI, the meta-data will likely exist in an annotation, but it could exist in an XML file (Candi, and Seam XML Extension for CDI).
For example, I am working on creating a standard interceptor for JCache 107. I can read the annotation from the getMethod of the InvocationContext, but if someone added the interception meta-data in an XML file, then it will not be available to InvocationContext.getMethod().getAnnotation(Cacheable.class).
I propose we have an extension interface that extends InvocationContext called CDIInvocationContext that has a getAnnotated. This way if someone annotates in an XML file, then it is available to implementors for interceptors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
LifeCycle Event Callbacks and Interceptors
by Jens Schumann
Hi all!
Recently I have noticed that OWB does not apply (class/method)
interceptors to lifecycle event callback methods. I 've chatted with Mark
and he referred me to the list. He tried to remember his research on this
topic and made the point that class interceptors should probably be
applied. However he has the feeling that pure method interceptors may not
be applied for lifecycle event callback methods since those methods are no
business methods.
It seems that neither the CDI spec nor the interceptor spec covers the
topic for all variations. After reading the interceptor spec again
(chapter "Interceptors for LifeCycle Event Callbacks") I would follow
Marks assertions.
What do you think? Is there anything missing within the CDI spec (and OWB
of course)?
Jens
13 years, 6 months
Proxy implementation leaks
by Christian Bauer
Started working with Weld 1.1.1 and found two issues that probably should be addressed (maybe just documented). They both look to me like leaking implementation details because proxies are used for components which are not @Singleton or @Dependent.
@ApplicationScoped
public class Bug {
public Bug() {
System.out.println("########## CONSTRUCT");
}
public void foo() {
System.out.println("##### FOO");
}
public static void main(String[] args) {
Weld weld = new Weld();
WeldContainer weldContainer = weld.initialize();
Bug bug = weldContainer.instance().select(Bug.class).get(); // Creates new instance of Bug
bug.foo(); // Creates new instance of Bug!!!
bug.foo(); // Uses existing instance
weld.shutdown();
}
}
The proxy of Bug will call its superclass constructor several times during the lifecycle of the Bug component. I don't know if that is really necessary, but if it is, you can now no longer use constructors to initialize your component. This is an issue because
- it's not documented that constructors of @ApplciationScoped (etc., proxied) components behave differently than @Singleton/@Dependent constructors
- even if it's documented, it's questionable if that really should be the case.
Taking away constructors as the primary means of initializing a component - e.g. obtaining resources such as database connections, reading config files, etc. - is a major change in the Java programming model. Users have to be strongly advised to use @PostConstruct then.
The other issue I immediately found is also related to behavior of proxies and how transitive initializing/injection is implemented (not sure if this is actually specified somewhere):
@ApplicationScoped
public class Foo {
@Inject
Bar bar;
}
@ApplicationScoped
public class Bar {
@Inject
Baz baz;
@PostConstruct
void init() { ... }
}
When I obtain a reference to Foo, I get a proxy of Foo with a reference to a proxy of Bar. The init() method of Bar is never called. The Baz component is never activated.
This means I can't transitively initialize an application-scoped graph of components. I was trying to use CDI for wiring in a Swing application and I imagine this would be a common usecase. It should either be documented that there is a difference between @Singleton/@Dependent and proxy-implemented scopes, or unification should be considered.
13 years, 7 months