October 2012 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-243) Consider built-in InjectionPoint not available for stateless session beans

by Martin Kouba (JIRA)

Martin Kouba created CDI-243: -------------------------------- Summary: Consider built-in InjectionPoint not available for stateless session beans Key: CDI-243 URL: https://issues.jboss.org/browse/CDI-243 Project: CDI Specification Issues Issue Type: Clarification Reporter: Martin Kouba Right now it should be possible to inject InjectionPoint metadata to dependent SLSB (see 5.5.7. Injection point metadata). I think it may lead to inconsistencies - SLSB should not have any state as it is usually pooled and reused for every invocation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
9
0 / 0

[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 resolved CDI-6. ------------------------- Resolution: Done > 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, 6 months

1
0
0 / 0

[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 resolved CDI-44. -------------------------- Resolution: Done > 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, 6 months

1
0
0 / 0

[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 resolved CDI-74. -------------------------- Resolution: Done > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger commented on CDI-43: ------------------------------------ Several consequences are implicit and we should discuss whether these are expected and/or should be declared explicitly: h3. Overriding As per current proposal of https://issues.jboss.org/browse/CDI-132, AnnotatedType.getMethods() returns even those methods that are overridden. Therefore in this situation: {code:JAVA} public class SimpleExtension implements Extension { void observe(@Observes @WithAnnotations(Blah.class) ProcessAnnotatedType<Bar> event) } public class Foo { @Blah public void ping() { } } public class Bar extends Foo { // no annotation here public void ping() { } } {code} The observer method would be invoked for ProcessAnnotatedType<Bar> even though Bar does not effectively use the @Blah annotation. h3. Modification by extensions Having a class {code:JAVA} @Bar public class Foo { } {code} there may be multiple observers of ProcessAnnotatedType<Foo>. These observers may modify the annotated type and therefore modify the annotations that the type provides. That means that if there are extension observer methods: {code:JAVA} void observe1(@Observes ProcessAnnotatedType<Foo> event) { event.setAnnotatedType(removeBar(event.getAnnotatedType)); // removes @Bar from the annotated type } void observe2(@Observes @WithAnnotations(Bar.class) ProcessAnnotatedType<Foo> event) { } {code} We can either: * resolve the observer methods upfront and invoke observe2 even if observe1 has been invoked before and the AnnotatedType no longer contains Bar which is required by observe2. * check the annotations of an AnnotatedType after each modification of the AnnotatedType and only invoke the other observer method if the AnnotatedType still matches its requirements The latter approach seems wrong. Since the order of observer method invocation is not specified, this could lead to random results. (the result would be dependent on the unspecified order) However, from the extension developer perspective it may be confusing if the observe2 method is invoked but the AnnotatedType contains no @Bar even though the observer methods defined @WithAnnotations(Bar.class), so we should probably document that this may happen. > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Pete Muir updated CDI-43: ------------------------- Fix Version/s: 1.1 (Proposed) (was: 1.1.PRD) > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1 (Proposed) > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in

by Jozef Hartinger (JIRA)

[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ] Jozef Hartinger reopened CDI-43: -------------------------------- The body of the @WithAnnotations annotation should be {code:JAVA} Class<? extends Annotation>[] value(); {code} instead of {code:JAVA} Class<?>[] value(); {code} so that if a class that is not an annotation type is used, this error is caught at the compile time > Allow Extensions to specify the annotations that they are interested in > ----------------------------------------------------------------------- > > Key: CDI-43 > URL: https://issues.jboss.org/browse/CDI-43 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Portable Extensions > Affects Versions: 1.0 > Reporter: Stuart Douglas > Assignee: Pete Muir > Fix For: 1.1.PRD > > > Currently portable extensions that wish to look for a specific annotation have to look through all availible classes in the ProcessAnnotatatedType event, which is quite inefficient. It would be good if extensions could do something like: > public void processAnnotatedType(@Observes @RequireAnnotations({(a)Unwraps.class}) ProcessAnnotatedType pat) > This could allow the container to take advantage of annotation indexing to improve boot time performance, as well as reducing uneeded processing in the observer. -- 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, 6 months

1
0
0 / 0

@PostConstruct on inherited class

by JJ Snyder

I'm investigating an issue dealing with @PostConstruct... Suppose I have the following 2 classes: public class X { @PostConstruct public void init() { } } public class Y extends X { @PostConstruct public void init() { } } and then in some other class I inject Y: public class Other { @Inject Y y; public void foo() { y.doSomething(); } According to the specs it's legal to have @PostConstruct defined on both X and Y. Also because Y defines init() it does not inherit X's init() method (section 4.2). So when an instance of Y is created which init() methods should be called for the @PostConstruct? What I am observing is that Y's init() method is called twice. Is this correct? I can't find any examples or any documentation that talks about this specific case. thanks, JJ

11 years, 6 months

3
4
0 / 0

No meeting today

by Pete Muir

All Due to JavaOne etc. I have not had time to produce any more changes to the spec for us to discuss for this week, therefore I'm going to cancel the meeting today, as there is not much to discuss. We will have a meeting next week! pete

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (CDI-173) Improve javadoc for event-firing methods

by Jozef Hartinger (Created) (JIRA)

Improve javadoc for event-firing methods ---------------------------------------- Key: CDI-173 URL: https://issues.jboss.org/browse/CDI-173 Project: CDI Specification Issues Issue Type: Feature Request Components: Javadoc and API Affects Versions: 1.0 Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1 (Proposed) The spec says {quote}Otherwise, the exception aborts processing of the event. No other observer methods of that event will be called. The BeanManager.fireEvent() or Event.fire() method rethrows the exception. If the exception is a checked exception, it is wrapped and rethrown as an (unchecked) ObserverException.{quote} The JavaDoc for BM.fireEvent() and Event.fire() only mentions IllegalArgumentException. The fact that the ObserverException or any other unchecked exception raised by an observer method should be mentioned. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

4
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev October 2012