Anyway Arne, let aside the state of the _current_ CDI-1.0 spec, is there something that you are missing which could be implemented easily? We could bring this to the EG in this case (it's a bit late, but anyway).
LieGrue, strub --- On Wed, 4/20/11, Gurkan Erdogdu <[email protected]> wrote: From: Gurkan Erdogdu <[email protected]> Subject: Re: Decorators with generic type-arguments To: [email protected] Date: Wednesday, April 20, 2011, 4:20 PM >>>The spec says „the actual type is assignable to…” and you wrote >>>isAssignableFrom so I think the correct behavior would be to >>>assign the Decorator. Anyway the code that applies a Decorator to a bean looks very good imho and I don’t think the >>>implementation is wrong here, but the code that checks if the delegate matches the decorator is not right.>>>The Spec says This is what we discussed early with RI and TCK guys. (weird words in spec and using in Java). Spec says "....the actual type is assignable to the upper bound.....", in Java it means to use "isAssignableFrom" method not the reverse :) Cheers 2011/4/20 Arne Limburg <[email protected]> Hi Gurkan, The spec says „the actual type is assignable to…” and you wrote isAssignableFrom so I think the correct behavior would be to assign the Decorator. Anyway the code that applies a Decorator to a bean looks very good imho and I don’t think the implementation is wrong here, but the code that checks if the delegate matches the decorator is not right. The Spec says“A decorator implements one or more bean types and intercepts business method invocations of beans which implement those bean types. These bean types are called decorated types.” (8)“The delegate type of a decorator must implement or extend every decorated type (with exactly the same type parameters).” (8.3.1) I have not tested it with Weld, I’ll do that and tell you. But anyway I think this should be fixed. In my examples every delegate has the same type-parameters as the decorator, so it should work. I have a fix now for the ClassUtil.setInterfaceTypeHierarchy. I’ll provide it via Jira. Unfortunately now I get another error saying something like my return type does not match… java.lang.IllegalArgumentException: Given bean type : class org.apache.owb.TestDecorator is not applicable for the bean instance : Name:null,WebBeans Type:DECORATOR,API Types:[java.lang.Object,org.apache.owb.TestDecorator,org.apache.owb.GenericInterface],Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] at org.apache.webbeans.container.BeanManagerImpl.getReference(BeanManagerImpl.java:914) at org.apache.webbeans.decorator.WebBeansDecoratorConfig.getDecoratorStack(WebBeansDecoratorConfig.java:160) at org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:216) at org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:98) at org.apache.owb.DecoratedBean_$$_javassist_0.isDecoratorCalled(DecoratedBean_$$_javassist_0.java) I’ll do some further investigation. Regards,Arne Von: Gurkan Erdogdu [mailto:[email protected]] Gesendet: Mittwoch, 20. April 2011 17:59 An: [email protected] Betreff: Re: Decorators with generic type-arguments In your example, spec says thatthe delegate type parameter is a type variable, the bean type parameter is an actual type, and the actual type is assignable to the upper bound, if any, of the type variable.Actual Type of Bean Class --> Scope Upper bound of type variable --> Annotation Scope.isAssignableFrom(Annotation) --> False Gurkan2011/4/20 Arne Limburg <[email protected]>Hi, Currently I try to get a Decorator working, that decorates an interface with a generic type argument. Although the Spec is quite clear about how to handle this (in 8.3.1) I am afraid, OpenWebBeans cannot handle it: This is the scenario @Decorator public class TestDecorator<A extends Annotation> implements GenericInterface<A> { @Inject @Any @Delegate private GenericInterface<A> delegate;} public class TestBean implements GenericInterface<Scope> { …} I have tried various combinations of actual type arguments in the Decorator (like Wildcard, raw type, …). The above leads to a definition error. Some other combinations lead to a behavior where the Decorator is not applied. Even declaring the Decorator with the same actual type variable (Scope in the example) does not work? Would you consider this a bug or do I read the spec wrong and this is not supported. Shall I fill a Jira Issue? Regards,Arne -- Arne Limburg - Enterprise Architectopen knowledge GmbH, Oldenburg Bismarckstraße 13, 26122 OldenburgMobil: +49 (0) 151 108 22 942Tel: +49 (0) 441 - 4082-0Fax: +49 (0) 441 - 4082-111 [email protected]http://www.openknowledge.de Registergericht: Amtsgericht Oldenburg, HRB 4670Geschäftsführer: Lars Röwekamp, Jens Schumann -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com -- Gurkan Erdogdu http://gurkanerdogdu.blogspot.com
