-
1. Re: Weld documentation Chapter 16. Portable extensions: QualifiedNameExtension
jharting Oct 23, 2013 9:39 AM (in response to bam)This should work fine. If the type is wrapped (isDirty() returns true) the original type is skipped but the wrapper will be used instead.
-
2. Re: Weld documentation Chapter 16. Portable extensions: QualifiedNameExtension
bam Oct 23, 2013 10:00 AM (in response to jharting)Thanks for the quick reply!
I understand the implementation of ProcessAnnotatedTypeImpl.getResultingAnnotatedType() as follows:
If isDirty() returns true, a new UnbackedAnnotatedType is created (using contents of the wrapper). That means, all subsequent calls are executed on the new UnbackedAnnotatedType and not on the wrapper. Therefore the method getAnnotation(final Class<T> annType) gets never called on the wrapper.Where do you see, that the wrapper will be used instead?
-
3. Re: Weld documentation Chapter 16. Portable extensions: QualifiedNameExtension
jharting Oct 23, 2013 12:06 PM (in response to bam)1 of 1 people found this helpfulI see your point now. What I meant was that the wrapper is read (when the UnbackedAnnotatedType is created) instead of the original one. Therefore, the new UnbackedAnnotatedType should be equivalent to the wrapper.
The problem here is with the example in the documentation. The extension should override getAnnotation(), getAnnotations() and isAnnotationPresent consistently. Otherwise an annotation you get from getAnnotation() may be different from what you get by iterating getAnnotations(). Even worse, you may get false from isAnnotationPresent(Foo.class) and yet get an instance from getAnnotation(Foo.class) in a similar scenario. I filed [WELD-1533] QualifiedNameExtension is incorrect - JBoss Issue Tracker for the documentation fix.
-
4. Re: Weld documentation Chapter 16. Portable extensions: QualifiedNameExtension
bam Oct 24, 2013 4:01 AM (in response to jharting)It sounds reasonable to have a consistent implementation in the example and I am looking forward to it!
I guess there are good reasons to create an UnbackedAnnotatedType. Could you point out those reasons, please?
I really liked the idea to be able to replace the AnnotatedType and right now it looks a kind of strange, having my AnnotatedType replaced behind the scenes.
If this approach is the desired one, the javadoc of ProcessAnnotatedType.setAnnotatedType(AnnotatedType<X> type) should also be modified. Right now it is misleading, as it states that the given "object" will be used:/**
* Replaces the {javax.enterprise.inject.spi.AnnotatedType}.
*
* @param type the new {javax.enterprise.inject.spi.AnnotatedType} object to use
*/
public void setAnnotatedType(AnnotatedType<X> type);