CDI 1.1 PFD submitted
by Pete Muir
All,
I've submitted the PFD to JCP.
Javadoc: http://docs.jboss.org/cdi/api/1.1-PFD/
Spec: http://docs.jboss.org/cdi/spec/1.1-PFD/
And the API jar is at javax.enterprise:cdi-api:1.1-PFD - currently in the JBoss repo only, but should be sync'd to central overnight.
Thanks to everyone who helped with this, in particular, I want to call out, in no particular order, and for lots of reasons, Arne Limburg, Stuart Douglas, Jozef Hartinger, Jason Greene, Mark Struberg, Joe Bergmark, JJ Snyder, Mike Brock, Martin Kouba, Fabian Marsuad, Paul Robinson, Tom Jenkinson, Jason Porter, John Ament, Marina Vatkina, Romain Manni-Bucau, Marek Schmidt, Gunnar Morling, David Blevins, Rick Hightower, Marius Bogoevici, Bill Shannon, Linda DeMichiel, Marko Luksa, Gavin King, Aslak Knutsen.
I purposefully haven't sent you a change log, as I haven't built it yet! I plan to add this, as well as @since tags, before we submit the final draft.
What happens next?
The final draft must be submitted on the 27th of March. The period between now and then is reserved for the RI and TCK teams to complete their work. With this in mind, the process for handling issues changes a bit. In order for us to address an issue, we must:
* be convinced the issue is a critical one
* not adding any major new functionality
* and most importantly, have the agreement of Martin and Jozef to include, as ultimately they must implement the change by the 27th!
So, if you do find a critical issue, please file an issue in JIRA as normal, but also raise it here, and we can discuss whether to include it.
Pete
11 years, 1 month
[JBoss JIRA] (CDI-268) Limitations in the SPI for creating beans
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-268?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-268.
---------------------------
Resolution: Done
Merged
> Limitations in the SPI for creating beans
> -----------------------------------------
>
> Key: CDI-268
> URL: https://issues.jboss.org/browse/CDI-268
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The CDI SPI provides an SPI that helps extension developers to build Bean implementations.
> An example follows:
> {code:JAVA}
> AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
> BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
> InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType);
> Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget);
> {code}
> This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior.
> However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI.
> A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean()
> On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed:
> *1.) InjectionPoint.getBean() always returns null*
> InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean.
> This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata).
> There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance:
> {code:JAVA}
> void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) {
> final InjectionPoint delegate = event.getInjectionPoint();
> if (delegate.getBean() == null) {
> event.setInjectionPoint(new ForwardingInjectionPoint() {
> @Override
> public Bean<?> getBean() {
> return bean;
> }
> @Override
> protected InjectionPoint delegate() {
> return delegate;
> }
> });
> }
> }
> {code}
> *2.) Decorators cannot be applied*
> Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not.
> To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice.
--
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, 1 month
[JBoss JIRA] (CDI-212) Add BeanManager.createDecorator() and BeanManager.createInterceptor()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-212?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-212:
-------------------------------
Here is the pull request - https://github.com/jboss/cdi/pull/177
> Add BeanManager.createDecorator() and BeanManager.createInterceptor()
> ---------------------------------------------------------------------
>
> Key: CDI-212
> URL: https://issues.jboss.org/browse/CDI-212
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Fix For: 1.1.PFD
>
>
> It is unclear from the specification whether the BeanManager.createBean() method should ever return an implementation of the Decorator or Interceptor interface.
> Method parameters of the createBean() method provide all the necessary information for constructing a Decorator implementation. Therefore, IMHO the method should return a container-provided Decorator implementation if the set of stereotypes returned by BeanAttributes.getStereotypes contains javax.decorator.Decorator.
> On the other hand, Interceptors do not fit this model because the AnnotatedType of the bean class is not available to the method and using the reflection API to scan the bean class directly would not be consistent with the rest of 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, 1 month
[JBoss JIRA] (CDI-268) Limitations in the SPI for creating beans
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-268?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-268:
-------------------------------
Here's the pull request - https://github.com/jboss/cdi/pull/177
> Limitations in the SPI for creating beans
> -----------------------------------------
>
> Key: CDI-268
> URL: https://issues.jboss.org/browse/CDI-268
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The CDI SPI provides an SPI that helps extension developers to build Bean implementations.
> An example follows:
> {code:JAVA}
> AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
> BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
> InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType);
> Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget);
> {code}
> This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior.
> However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI.
> A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean()
> On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed:
> *1.) InjectionPoint.getBean() always returns null*
> InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean.
> This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata).
> There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance:
> {code:JAVA}
> void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) {
> final InjectionPoint delegate = event.getInjectionPoint();
> if (delegate.getBean() == null) {
> event.setInjectionPoint(new ForwardingInjectionPoint() {
> @Override
> public Bean<?> getBean() {
> return bean;
> }
> @Override
> protected InjectionPoint delegate() {
> return delegate;
> }
> });
> }
> }
> {code}
> *2.) Decorators cannot be applied*
> Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not.
> To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice.
--
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, 1 month
[JBoss JIRA] (CDI-268) Limitations in the SPI for creating beans
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-268?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-268:
-------------------------------
Yeah, that is a bit cleaner, and I'm happy to spec that :-)
> Limitations in the SPI for creating beans
> -----------------------------------------
>
> Key: CDI-268
> URL: https://issues.jboss.org/browse/CDI-268
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The CDI SPI provides an SPI that helps extension developers to build Bean implementations.
> An example follows:
> {code:JAVA}
> AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
> BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
> InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType);
> Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget);
> {code}
> This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior.
> However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI.
> A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean()
> On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed:
> *1.) InjectionPoint.getBean() always returns null*
> InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean.
> This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata).
> There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance:
> {code:JAVA}
> void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) {
> final InjectionPoint delegate = event.getInjectionPoint();
> if (delegate.getBean() == null) {
> event.setInjectionPoint(new ForwardingInjectionPoint() {
> @Override
> public Bean<?> getBean() {
> return bean;
> }
> @Override
> protected InjectionPoint delegate() {
> return delegate;
> }
> });
> }
> }
> {code}
> *2.) Decorators cannot be applied*
> Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not.
> To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice.
--
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, 1 month
[JBoss JIRA] (CDI-268) Limitations in the SPI for creating beans
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-268?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg edited comment on CDI-268 at 2/27/13 4:15 AM:
-----------------------------------------------------------
I discussed this problem with Mark Struberg for our implementation in OpenWebBeans some time ago.
My proposal (which is quite similar to the handler, but feels cleaner to me):
Introduce an InjectionTargetFactory that may be called by the bean itself (i.e. in the constructor) and receives the Bean instance:
{code}
public interface InjectionTargetFactory {
public <T> InjectionTarget<T> createInjectionTarget(Bean<T> bean);
}
{code}
This would lead to the following code for the above example:
{code}
AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
Bean<Foo> bean = manager.createBean(attributes, Foo.class, manager.getInjectionTargetFactory());
{code}
When the SPI implementor wants to hook into InjectionTarget creation he can wrap the InjectionTargetFactory. The method BeanManager#createInjectionTarget would stay in the API (although it is not used in this use case).
was (Author: arnelim):
I discussed this problem with Mark for our implementation in OpenWebBeans.
My proposal (which is quite similar to the handler, but feels cleaner to me):
Introduce an InjectionTargetFactory that may be called by the bean itself (i.e. in the constructor) and receives the Bean instance:
{code}
public interface InjectionTargetFactory {
public <T> InjectionTarget<T> createInjectionTarget(Bean<T> bean);
}
{code}
This would lead to the following code for the above example:
{code}
AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
Bean<Foo> bean = manager.createBean(attributes, Foo.class, manager.getInjectionTargetFactory());
{code}
When the SPI implementor wants to hook into InjectionTarget creation he can wrap the InjectionTargetFactory. The method BeanManager#createInjectionTarget would stay in the API (although it is not used in this use case).
> Limitations in the SPI for creating beans
> -----------------------------------------
>
> Key: CDI-268
> URL: https://issues.jboss.org/browse/CDI-268
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The CDI SPI provides an SPI that helps extension developers to build Bean implementations.
> An example follows:
> {code:JAVA}
> AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
> BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
> InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType);
> Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget);
> {code}
> This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior.
> However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI.
> A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean()
> On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed:
> *1.) InjectionPoint.getBean() always returns null*
> InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean.
> This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata).
> There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance:
> {code:JAVA}
> void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) {
> final InjectionPoint delegate = event.getInjectionPoint();
> if (delegate.getBean() == null) {
> event.setInjectionPoint(new ForwardingInjectionPoint() {
> @Override
> public Bean<?> getBean() {
> return bean;
> }
> @Override
> protected InjectionPoint delegate() {
> return delegate;
> }
> });
> }
> }
> {code}
> *2.) Decorators cannot be applied*
> Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not.
> To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice.
--
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, 1 month
[JBoss JIRA] (CDI-268) Limitations in the SPI for creating beans
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-268?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-268:
----------------------------------
I discussed this problem with Mark for our implementation in OpenWebBeans.
My proposal (which is quite similar to the handler, but feels cleaner to me):
Introduce an InjectionTargetFactory that may be called by the bean itself (i.e. in the constructor) and receives the Bean instance:
{code}
public interface InjectionTargetFactory {
public <T> InjectionTarget<T> createInjectionTarget(Bean<T> bean);
}
{code}
This would lead to the following code for the above example:
{code}
AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
Bean<Foo> bean = manager.createBean(attributes, Foo.class, manager.getInjectionTargetFactory());
{code}
When the SPI implementor wants to hook into InjectionTarget creation he can wrap the InjectionTargetFactory. The method BeanManager#createInjectionTarget would stay in the API (although it is not used in this use case).
> Limitations in the SPI for creating beans
> -----------------------------------------
>
> Key: CDI-268
> URL: https://issues.jboss.org/browse/CDI-268
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> The CDI SPI provides an SPI that helps extension developers to build Bean implementations.
> An example follows:
> {code:JAVA}
> AnnotatedType<Foo> annotatedType = manager.createAnnotatedType(Foo.class);
> BeanAttributes<Foo> attributes = manager.createBeanAttributes(annotatedType);
> InjectionTarget<Foo> injectionTarget = manager.createInjectionTarget(annotatedType);
> Bean<Foo> bean = manager.createBean(attributes, Foo.class, injectionTarget);
> {code}
> This sequence allows an extension to easily build Bean<Foo>. Obviously, the extension could modify the artifacts along the way to modify the behavior.
> However, this SPI has limitations. There is a circular dependency between the initialization of Bean and InjectionTarget which is not expressed by the SPI.
> A Bean implemetation (be it container-provided one or not) almost always uses an InjectionTarget to delegate bean instance creation and destruction to. So far so good as the InjectionTarget is one of the arguments of BeanManager.createBean()
> On the other hand, the InjectionTarget also needs a reference to a Bean instance at initialization should it serve as an InjectionTarget for a Bean. This is not obvious but there are two reasons why this is needed:
> *1.) InjectionPoint.getBean() always returns null*
> InjectionTarget.getInjectionPoints() returns a set of InjectionPoint instances. The InjectionPoint has the method getBean(). This method would always return null (e.g. for InjectionTarget<Foo> above) because there is no way to tell the container that this InjectionTarget is an InjectionTarget of a Bean.
> This causes problems since the getBean() method is used for validation of injection points - certain types of injection points are allowed to be placed on beans only (e.g. Bean metadata, injection point metadata).
> There exists a workaround for this where the ProcessInjectionPoint is used to wrap every such InjectionPoint with a wrapper that returns the Bean instance:
> {code:JAVA}
> void wrapInjectionPoints(@Observes ProcessInjectionPoint<Foo, ?> event) {
> final InjectionPoint delegate = event.getInjectionPoint();
> if (delegate.getBean() == null) {
> event.setInjectionPoint(new ForwardingInjectionPoint() {
> @Override
> public Bean<?> getBean() {
> return bean;
> }
> @Override
> protected InjectionPoint delegate() {
> return delegate;
> }
> });
> }
> }
> {code}
> *2.) Decorators cannot be applied*
> Bean<Foo> in the example above would not be decorated even if there were enabled decorators matching the bean. This is because the InjectionTarget, which takes care of creating instances and whose produce() method is responsible for building decorators for the instance does not know whether what it creates actually is a bean or not. Even if it knew, it would need to know the types and qualifiers of the bean, which it does not.
> To sum it up: Although BeanAttributes, Bean and InjectionTarget seem to be independent layers out of which a Bean can be composed, there are actually circular relations which the SPI currently fails to notice.
--
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, 1 month
[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Arne Limburg (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Arne Limburg commented on CDI-271:
----------------------------------
Done: CDI-323
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Assignee: Arne Limburg
> Fix For: 1.1.PFD
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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, 1 month