Discussion:
[seam-dev] CDI EG requires feedback
Pete Muir
2012-08-15 13:17:24 UTC
Permalink
All, the CDI EG requires feedback on an item in the spec which is not clear, and has been implemented differently between implementations, and is not TCK tested. As Seam-dev contains lots of extensions authors, requesting feedback. Please either send direct to me, or post to cdi-***@lists.jboss.org :-)

Stuart, your feedback on this would be good, as it relates to XML config.

------------------------------------------------------------------------------------------------------------------------------------------------

Multiple Annotated Types
====================

https://issues.jboss.org/browse/CDI-58

This concerns whether there can be greater than one annotated type per class instance in the JVM. Gavin intended there should be, principally to support an XML configuration dialect, which could introduce multiple versions of a class, each with a different qualifier. However, this is not TCK tested, and implementations vary in how they support this.

We discussed that this makes an implementation considerably more complex (as there is no easy way to uniquely identify an annotated type e.g. for serialization), and also is pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each class, making it hard to know which one you want to change).

We looked at alternative solutions, and concluded that if all use cases can be satisfied by adding a new bean, rather than a new annotated type, we would like to explicitly specify that there is only one annotated type per class instance. In CDI 1.1 it is already much easier to add and manipulate beans from annotated types, so we believe that the correct thing here is take this route.

------------------------------------------------------------------------------------------------------------------------------------------------

Does anyone create multiple AnnotatedTypes per class instance? If so, can you please describe:

a) why you need to do this
b) whether you could reimplement by directly creating beans (given that CDI 1.1 allows you to [1])
c) how much effort it would be to reimplement/how much of your codebase this would affect

Thanks!

Pete

[1]

BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
Bean b = beanManager.createBean(ba, clazz, it);

or

BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
Bean b = beanManager.createBean(ba, clazz, p);

The Bean can then be registered using

afterBeanDiscovery.addBean(b);
Lincoln Baxter, III
2012-08-15 16:42:41 UTC
Permalink
I believe that Forge creates new Annotated Types to replace the existing
one in the event-bus extension. This is done so that Qualifiers may be
added to parameters of event observers.

You can see the code here. I'm not sure if this is related to your
discussion, but it seems close so I thought I would mention it:

https://github.com/forge/core/blob/master/event-bus-api/src/main/java/org/jboss/forge/bus/cdi/ObserverCaptureExtension.java

This extension took a good deal of work to produce, and is used throughout
Forge. As long as we can capture events like we are doing here, it could be
re-implemented, but it would potentially be a lot of work.

~Lincoln
Post by Pete Muir
All, the CDI EG requires feedback on an item in the spec which is not
clear, and has been implemented differently between implementations, and is
not TCK tested. As Seam-dev contains lots of extensions authors, requesting
feedback. Please either send direct to me, or post to
Stuart, your feedback on this would be good, as it relates to XML config.
------------------------------------------------------------------------------------------------------------------------------------------------
Multiple Annotated Types
====================
https://issues.jboss.org/browse/CDI-58
This concerns whether there can be greater than one annotated type per
class instance in the JVM. Gavin intended there should be, principally to
support an XML configuration dialect, which could introduce multiple
versions of a class, each with a different qualifier. However, this is not
TCK tested, and implementations vary in how they support this.
We discussed that this makes an implementation considerably more complex
(as there is no easy way to uniquely identify an annotated type e.g. for
serialization), and also is pretty confusing for a user (as you now get
multiple ProcessAnnotatedType events for each class, making it hard to know
which one you want to change).
We looked at alternative solutions, and concluded that if all use cases
can be satisfied by adding a new bean, rather than a new annotated type, we
would like to explicitly specify that there is only one annotated type per
class instance. In CDI 1.1 it is already much easier to add and manipulate
beans from annotated types, so we believe that the correct thing here is
take this route.
------------------------------------------------------------------------------------------------------------------------------------------------
Does anyone create multiple AnnotatedTypes per class instance? If so, can
a) why you need to do this
b) whether you could reimplement by directly creating beans (given that
CDI 1.1 allows you to [1])
c) how much effort it would be to reimplement/how much of your codebase this would affect
Thanks!
Pete
[1]
BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
Bean b = beanManager.createBean(ba, clazz, it);
or
BeanAttributes ba =
beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
Bean b = beanManager.createBean(ba, clazz, p);
The Bean can then be registered using
afterBeanDiscovery.addBean(b);
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
Pete Muir
2012-08-15 17:07:18 UTC
Permalink
This would still work, you are replacing an existing annotated type, not adding a new one for the same type.

We're talking about having an AnnotatedType<Foo>, and adding another one of AnnotatedType<Foo>.
I believe that Forge creates new Annotated Types to replace the existing one in the event-bus extension. This is done so that Qualifiers may be added to parameters of event observers.
https://github.com/forge/core/blob/master/event-bus-api/src/main/java/org/jboss/forge/bus/cdi/ObserverCaptureExtension.java
This extension took a good deal of work to produce, and is used throughout Forge. As long as we can capture events like we are doing here, it could be re-implemented, but it would potentially be a lot of work.
~Lincoln
Stuart, your feedback on this would be good, as it relates to XML config.
------------------------------------------------------------------------------------------------------------------------------------------------
Multiple Annotated Types
====================
https://issues.jboss.org/browse/CDI-58
This concerns whether there can be greater than one annotated type per class instance in the JVM. Gavin intended there should be, principally to support an XML configuration dialect, which could introduce multiple versions of a class, each with a different qualifier. However, this is not TCK tested, and implementations vary in how they support this.
We discussed that this makes an implementation considerably more complex (as there is no easy way to uniquely identify an annotated type e.g. for serialization), and also is pretty confusing for a user (as you now get multiple ProcessAnnotatedType events for each class, making it hard to know which one you want to change).
We looked at alternative solutions, and concluded that if all use cases can be satisfied by adding a new bean, rather than a new annotated type, we would like to explicitly specify that there is only one annotated type per class instance. In CDI 1.1 it is already much easier to add and manipulate beans from annotated types, so we believe that the correct thing here is take this route.
------------------------------------------------------------------------------------------------------------------------------------------------
a) why you need to do this
b) whether you could reimplement by directly creating beans (given that CDI 1.1 allows you to [1])
c) how much effort it would be to reimplement/how much of your codebase this would affect
Thanks!
Pete
[1]
BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
Bean b = beanManager.createBean(ba, clazz, it);
or
BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
Bean b = beanManager.createBean(ba, clazz, p);
The Bean can then be registered using
afterBeanDiscovery.addBean(b);
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
Mark Struberg
2012-08-15 17:53:21 UTC
Permalink
To make it even more clear what Pete just stated: People added multiple different AnnotatedTypes to the same class because they wanted to get multiple different 'Managed Bean' for the same class. If we clarify that only 1 AnnotatedType instance exists per class, then you would do the same by just providing multiple Bean<T> instances directly.

LieGrue,
strub



----- Original Message -----
Sent: Wednesday, August 15, 2012 7:07 PM
Subject: Re: [seam-dev] CDI EG requires feedback
T his would still work, you are replacing an existing annotated type, not adding
a new one for the same type.
We're talking about having an AnnotatedType<Foo>, and adding another
one of AnnotatedType<Foo>.
Post by Lincoln Baxter, III
I believe that Forge creates new Annotated Types to replace the existing
one in the event-bus extension. This is done so that Qualifiers may be added to
parameters of event observers.
Post by Lincoln Baxter, III
You can see the code here. I'm not sure if this is related to your
https://github.com/forge/core/blob/master/event-bus-api/src/main/java/org/jboss/forge/bus/cdi/ObserverCaptureExtension.java
Post by Lincoln Baxter, III
This extension took a good deal of work to produce, and is used throughout
Forge. As long as we can capture events like we are doing here, it could be
re-implemented, but it would potentially be a lot of work.
Post by Lincoln Baxter, III
~Lincoln
All, the CDI EG requires feedback on an item in the spec which is not
clear, and has been implemented differently between implementations, and is not
TCK tested. As Seam-dev contains lots of extensions authors, requesting
:-)
Post by Lincoln Baxter, III
Stuart, your feedback on this would be good, as it relates to XML config.
------------------------------------------------------------------------------------------------------------------------------------------------
Post by Lincoln Baxter, III
Multiple Annotated Types
====================
https://issues.jboss.org/browse/CDI-58
This concerns whether there can be greater than one annotated type per
class instance in the JVM. Gavin intended there should be, principally to
support an XML configuration dialect, which could introduce multiple versions of
a class, each with a different qualifier. However, this is not TCK tested, and
implementations vary in how they support this.
Post by Lincoln Baxter, III
We discussed that this makes an implementation considerably more complex
(as there is no easy way to uniquely identify an annotated type e.g. for
serialization), and also is pretty confusing for a user (as you now get multiple
ProcessAnnotatedType events for each class, making it hard to know which one you
want to change).
Post by Lincoln Baxter, III
We looked at alternative solutions, and concluded that if all use cases can
be satisfied by adding a new bean, rather than a new annotated type, we would
like to explicitly specify that there is only one annotated type per class
instance. In CDI 1.1 it is already much easier to add and manipulate beans from
annotated types, so we believe that the correct thing here is take this route.
------------------------------------------------------------------------------------------------------------------------------------------------
Post by Lincoln Baxter, III
Does anyone create multiple AnnotatedTypes per class instance? If so, can
a) why you need to do this
b) whether you could reimplement by directly creating beans (given that CDI
1.1 allows you to [1])
Post by Lincoln Baxter, III
c) how much effort it would be to reimplement/how much of your codebase
this would affect
Post by Lincoln Baxter, III
Thanks!
Pete
[1]
BeanAttributes ba = beanManager.cerateBeanAttributes(annotatedType);
InjectionTarget it = beanmanager.createInjectionTarget(annotatedType);
Bean b = beanManager.createBean(ba, clazz, it);
or
BeanAttributes ba =
beanManager.cerateBeanAttributes(annotatedFieldOrMethod);
Post by Lincoln Baxter, III
Producer p = beanmanager.createProducer(annotatedFieldOrMethod);
Bean b = beanManager.createBean(ba, clazz, p);
The Bean can then be registered using
afterBeanDiscovery.addBean(b);
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
_______________________________________________
seam-dev mailing list
https://lists.jboss.org/mailman/listinfo/seam-dev
Loading...