Hey guys. Anyone know why WeldClassImpl sets superclass to Object.class for some classes? This causes weld not to inject fields, declared in superclasses, where the annotatedType is supplied by an extension. (OK, not in all cases, only in cases where the annotatedType is detected as being modified). See https://issues.jboss.org/browse/WELD-1144 Take a look at https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel... I'm thinking of changing this to something along the lines of: this.superclass = classTransformer.loadClass(annotatedType.getJavaClass().getSuperclass()); This change does break two tests (SuperTypeTest and SuperclassModifiedTest), but IMO for these two tests to pass, we should change Beans.getFieldInjectionPoints() so it returns only the fields that were returned by AnnotatedType.getFields(). Is there any other reason why WeldClassImpl would need to set this.superclass to Object.class? Marko _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

Hmm, actually the example Extension in WELD-1144 does return an AnnotatedType which returns *all* the fields (even the superclass' fields) in getFields(). The problem is that Beans.getFieldInjectionPoints() only looks at *declared* fields in WeldClass and then calls WeldClass.getSuperClass() and looks at its declared fields (in this case, the superclass is Object, so Weld actually only sees the actual class' fields). So if we can't change WeldClass.superclass, we should change Beans.getFieldInjectionPoints so it takes into account all the fields returned by WeldClass.getFields(). Of course these would need to be partitioned (as getFieldInjectionPoints() actually returns a List<Set<FieldInjectionPoint>> - a Set of field injection points for every class in the hierarchy). WDYT? On 19.7.2012 23:18, Stuart Douglas wrote: > The assumption is that if an annotated type is registered via an > extension it must also include all superclass fields as well. > > This gives much more flexibility to extension authors, otherwise it > is basically impossible to modify superclass annotations. > > Stuart > > > On 20/07/2012, at 12:10 AM, Marko Lukša wrote: > >> Hey guys. >> >> Anyone know why WeldClassImpl sets superclass to Object.class for some >> classes? This causes weld not to inject fields, declared in >> superclasses, where the annotatedType is supplied by an extension. (OK, >> not in all cases, only in cases where the annotatedType is detected as >> being modified). See https://issues.jboss.org/browse/WELD-1144 >> >> Take a look at >> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel... >> >> >> I'm thinking of changing this to something along the lines of: >> >> this.superclass = >> classTransformer.loadClass(annotatedType.getJavaClass().getSuperclass()); >> >> >> This change does break two tests (SuperTypeTest and >> SuperclassModifiedTest), but IMO for these two tests to pass, we should >> change Beans.getFieldInjectionPoints() so it returns only the fields >> that were returned by AnnotatedType.getFields(). >> >> Is there any other reason why WeldClassImpl would need to set >> this.superclass to Object.class? >> >> Marko >> >> >> >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev