users@jaxb.java.net

Re: Finding implementation class from FieldOutline?

From: Aleksei Valikov <valikov_at_gmx.net>
Date: Tue, 16 Dec 2008 20:28:47 +0100

Hi.

> Ok, looking at the JAXB source code, it looks like the sequence is: From my
> FieldInfo, get the CPropertyInfo. Cast that to a CElementPropertyInfo. On
> that, call getTypes(), and (I assume) get the first element assuming it only
> has one. I then call getTarget() and cast that to a CClassInfo. From there I
> can get the user specified type.
>
> That seems kind of horrible, and there are a bunch of failure points there
> that I don't understand. Does getTypes() always return one element? What
> does it really represent? What if getTarget() isn't a CClassInfo?
>
> It's pretty nasty - is there really no better way to do this?

Yes, it is. And no, there is not better way.

If you work further on, you'll understand the logic behind it.

(1) Cast CPropertyInfo to CElementPropertyInfo - this applies to
"element" properties. There's also attribute, value and reference
properties.

(2) getTypes() returns you type references which can be contained in
the given property. If you have homogeneous property, you'll get one
type there, but you can also get multiple types returned.

(3) When you got a type (CTypeRef), you call getTarget(). You get a
CNonElement there, but this is not necessarily CClassInfo. You can get
CBuiltinLeafInfo for built-in types (like primitives or xs:* schema
types), CEnumLeafInfo for enums, CClassInfo for complex types and
CClassRef for class references (for instance if you have <jaxb:class
ref="com.acme.foo.MyClass"/> in your bindings).

The complexity here is due to the complexity the model can have.

I've worked through all of this in hj3 and I can tell you this is not
trivial. To get you started, I've attached the CClassifyingVisitor
class which can distinguish different property types.

Bye.
/lexi