As discussed on IRC:

<luksa> kennardconsult: the thing is, I did post a message to weld-dev mailing list asking why weld sets Object.class as the superclass for some beans (ths is what's causing your problem)
<kennardconsult> luksa: there was no response?
<luksa> kennardconsult: and I haven't really received any useful info on that yet. Supposedly, it needs to be so...
<luksa> http://lists.jboss.org/pipermail/weld-dev/2012-July/003046.html
...
<alesj> kennardconsult: I think the superclass behavior is defined by the spec, as Stuart suggested
...
<pmuir> luksa: it probably is, but unlesss you are 100% sure, i woudn't change the behavior
<pmuir> e.g gf might be using it, or wls
<kennardconsult> alesj: okay, so can somebody reconcile the spec with what I'm trying to do in WELD-1144. Is what I'm attempting illegal?
<alesj> kennardconsult: pmuir is best there, wrt spec - but I do rememebr I was looking at that superclass before, and it made sense at the end not to change the behavior
<kennardconsult> But in that case you can never do 1144, right? luksa, having looked at 1144, is what I'm trying to do unreasonable?
<alesj> kennardconsult: it can be done, afair - but your a bit stuck with less portable code, e.g. you need to use Weld's custom classes -
<alesj> - if I still rememeber correctly -
<kennardconsult> alesj: my code in 1144 is basically the same code as in the CDI Reference Guide. So I think something is broken here
<alesj> pmuir: ^ broken ref guide?
<pmuir> looking
<kennardconsult> pmuir: chapter 16.7 "Wrapping an AnnotatedType". You basically need to put a disclaimer saying 'this code will not work if any of your CDI beans have superclasses"
<luksa> kennardconsult: alesj: I really don't see how setting the superclass to Object.class could ever be OK.
<pmuir> luksa: so the issue is that annotatedType.getFields() doesn't return the fields on the super class, but then weld ignores the super class?
<pmuir> the idea is that the AnnotatedField list should contain all fields to inject in the entire class hierarchy
<pmuir> otherwise this can't work in any consistent way
<luksa> pmuir: yes, Beans.getFieldInjectionPoints only gets the declared fields of a WeldClass and then moves on to the superclass (which is Object.class in some cases)... therefore, it completely skips the declared fields of the actual superclass
<luksa> pmuir: and yes, since AnnotatedType.getFields() can be whatever someone wants, Beans.getFieldInjectionPoints() should not bypass it (by walking up the hierarchy itself)
<luksa> pmuir: ops, there are two Beans.getFieldInjectionPoints() methods.. I'm talking about the one at around line 189: public static List<Set<FieldInjectionPoint<?, ?>>> getFieldInjectionPoints(Bean<?> declaringBean, WeldClass<?> weldClass) {
<pmuir> luksa: yeah, I think that is more the problem
<pmuir> than the fact that Object.class is the superclass
<pmuir> ie. i would try to fix Beans
<pmuir> to do the correct injections
<pmuir> and basically that if someone has overridden getFields on AnnotatedType
<pmuir> they should be canonical
<luksa> mhm
<luksa> pmuir: ok, I'll go along that route...
<luksa> pmuir: tnx for the help
<kennardconsult> Thanks luksa, pmuir! I'll keep an eye on the JIRA
<pmuir> luksa: np