[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 commented on CDI-43:
------------------------------
At the EG meeting we discussed this, and everyone agreed we should move ahead with it. These comments were made:
* That we need to define whether we look on not only the concrete class for annotations, but also super types (feeling was that we should)
* That this should be defined as a filter, not as a hint (ie. container will use this, not may use this)
* That we may want to consider scanning not only annotations but also meta annotations. Stuart, any comment on whether this will affect performance substantially.
We also discussed whether it should be RetentionPolicy.CLASS or RetentionPolicy.RUNTIME. Stuart proposed CLASS, as this is then available for a bytecode reader, but not for Reflection/classloading, which would allow an extension which defines this to continue running in CDI 1.0. In general, we felt this was not necessary, as most extensions will simply upgrade to CDI 1.1, and also make use of other CDI 1.1 features, such as new container lifecycle events.
We discussed naming, and concluded we need a different name.
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (CDI-78) Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-78?page=com.atlassian.jira.plugin.sys... ]
Jozef Hartinger commented on CDI-78:
------------------------------------
The tricky part of having
{code:JAVA}
@Inject
InjectionPoint ip
{code}
in a Decorator is that one may have multiple decorated beans such as:
{code:JAVA}
public class Foo implements Readable {
public int read(CharBuffer cb) {
return 0;
}
}
@ApplicationScoped
public class Bar implements Readable {
public int read(CharBuffer cb) {
return 0;
}
}
{code}
Both beans would be decorated by a decorator:
{code:JAVA}
public class ReadableDecorator implements Readable {
@Inject @Delegate
Readable delegate;
@Inject
InjectionPoint ip;
public int read(CharBuffer cb) {
return delegate.read(cb);
}
}
{code}
The problem is that there is no InjectionPoint metadata to be injected into decorator when the normal-scoped bean (Bar) is decorated. At the same time there is no problem decorating Foo since it is dependent and InjectionPoint metadata is available.
> Clarify how isDelegate() behaves on InjectionPoint, and what happens when an InjectionPoint is injected into a Decorator
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-78
> URL: https://issues.jboss.org/browse/CDI-78
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators
> Affects Versions: 1.0
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.EDR1
>
>
> The InjectionPoint should be that of the injection into the consumer, and isDelegate() should return false.
--
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
13 years, 11 months
[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:
------------------------------------
I don't think this should be a type-level annotation - I like the original proposal much more. Bootstrap optimization that a container may perform based on this metadata is one of the benefits of this change. In addition, this could also serve as a convenient method of filtering container lifecycle events for extension authors - not unlike how qualifiers can be used to filter normal events. For that, per observer method declarations would be necessary.
{code:JAVA}
public class SeamExtension implements Extension {
public void registerRestClientInjectionPoints(@Observes @HandlesTypes(RestClient.class) ProcessAnnotatedType<?> type) {
// TODO register @RestClient injection points
}
public void registerExceptionHandlerClasses(@Observes @HandlesTypes(HandlesExceptions.class) ProcessAnnotatedType<?> type) {
// TODO register exception handlers
}
}
{code}
It would be guaranteed that if the "registerExceptionHandlerClasses" observer method is called, the annotated type is annotated with the @HandlesException annotation.
Furthermore, if we choose a different name for the annotation than "HandlesTypes", I would suggest to drop the option to use the annotation to specify superclasses and interfaces implemented by the event (since this can already be done by a wildcard in the observer method declaration) and leave only the option of filtering based on annotations.
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (CDI-43) Allow Extensions to specify the annotations that they are interested in
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/CDI-43?page=com.atlassian.jira.plugin.sys... ]
Stuart Douglas commented on CDI-43:
-----------------------------------
I think that should should also apply to ProcessBean, ProcessProducer etc. In this case the even is only delivered if the declaring class (i.e. Bean.getBeanClass() ) meets these requirements.
Also "Note that if even one extension doesn't use this feature, the performance benefit is lost." is not strictly true. There can still be a saving if the extension without this annotation either:
- Does not observer ProcessAnnotatedType
- Only looks for class level annotations (AnnotatedMethod/AnnotatedField objects are very expensive to create)
It is only if an extension does not use this annotation and also inspects every field and method of every class that there is no performance benefit.
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[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 edited comment on CDI-43 at 8/20/12 1:48 PM:
-------------------------------------------------------
A more formal proposal:
Add
{code}
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface HandlesTypes {
Class[] value();
}
{code}
(Name is a strawman...)
This annotation can be applied to an extension class, and provides a hint to the container about classes or annotations which this extension is interested in.
If this annotation is used, the container, as a performance optimisation, may only call ProcessAnnotatedType observer methods:
* that have the event type (or a super class or super interface of the event type) in the set of handled types
* that have an annotation (applied to the type, constructor, constructor parameter, method, method parameter or field) that is in the set of handled types
and may not call a ProcessAnnotatedType observer method for other event types.
was (Author: pmuir):
A more formal proposal:
Add
{code}
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.CLASS)
public @interface HandlesTypes {
Class[] value();
}
{code}
(Name is a strawman...)
This annotation can be applied to an extension class, and provides a hint to the container about classes or annotations which this extension is interested in.
If this annotation is used, the container, as a performance optimisation, may only call ProcessAnnotatedType observer methods:
* that have the event type (or a super class or super interface of the event type) in the set of handled types
* that have an annotation (applied to the type, constructor, constructor parameter, method, method parameter or field) that is in the set of handled types
and may not call a ProcessAnnotatedType observer method for other event types.
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[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 edited comment on CDI-43 at 8/20/12 1:47 PM:
-------------------------------------------------------
A more formal proposal:
Add
{code}
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.CLASS)
public @interface HandlesTypes {
Class[] value();
}
{code}
(Name is a strawman...)
This annotation can be applied to an extension class, and provides a hint to the container about classes or annotations which this extension is interested in.
If this annotation is used, the container, as a performance optimisation, may only call ProcessAnnotatedType observer methods:
* that have the event type (or a super class or super interface of the event type) in the set of handled types
* that have an annotation (applied to the type, constructor, constructor parameter, method, method parameter or field) that is in the set of handled types
and may not call a ProcessAnnotatedType observer method for other event types.
was (Author: pmuir):
A more formal proposal:
Add
{code}
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface HandlesTypes {
Class[] value();
}
{code}
(Name is a strawman...)
This annotation can be applied to an extension class, and provides a hint to the container about classes or annotations which this extension is interested in.
If this annotation is used, the container, as a performance optimisation, may only call ProcessAnnotatedType observer methods:
* that have the event type (or a super class or super interface of the event type) in the set of handled types
* that have an annotation (applied to the type, constructor, constructor parameter, method, method parameter or field) that is in the set of handled types
and may not call a ProcessAnnotatedType observer method for other event types.
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[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 commented on CDI-43:
------------------------------
A more formal proposal:
Add
{code}
@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface HandlesTypes {
Class[] value();
}
{code}
(Name is a strawman...)
This annotation can be applied to an extension class, and provides a hint to the container about classes or annotations which this extension is interested in.
If this annotation is used, the container, as a performance optimisation, may only call ProcessAnnotatedType observer methods:
* that have the event type (or a super class or super interface of the event type) in the set of handled types
* that have an annotation (applied to the type, constructor, constructor parameter, method, method parameter or field) that is in the set of handled types
and may not call a ProcessAnnotatedType observer method for other event types.
> 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
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
Potential topic for discussion on today's weekly meeting
by Joseph Bergmark
https://issues.jboss.org/browse/CDI-223
https://issues.jboss.org/browse/CDI-219
https://issues.jboss.org/browse/CDI-235
These 3 JIRA issues basically boil down to 2 related
discussions/clarifications.
1) Should it be made more clear in the spec that request context that is
created for a @Remote ejb (or really any time request context does not
already exist on the thread) goes away when that method call finishes.
This relates to the second issue, because this might extend to
@PostConstruct & @PreDestroy if request scope should be active there as
well.
6.7.1 currently states the request scope is active:
"during any remote method invocation of any EJB, during any asynchronous
method invocation of any EJB, during any
call to an EJB timeout method and during message delivery to any EJB
message-driven bean, and"
and it ends:
"after the EJB remote method invocation, asynchronous method invocation,
timeout or message delivery completes, or"
2) What scopes should be active during lifecycle callbacks to EJBs. For
example @PostConstruct in a @Remote ejb, or @PostConstruct on a @Startup
@Singleton EJB might both be instances where users might want request
context to be active if its not already. It is not even clear to me
currently that application context should be active during these methods.
There is one mention of @Predestroy in 6.7.3 regarding when application
scope should be active, but its not specific to EJB:
"when the disposer method or @PreDestroy callback of any bean with any
normal scope other than @ApplicationScoped is called."
Sincerely,
Joe
13 years, 11 months