Hi Markus,
On Sat, Dec 19, 2009 at 3:51 PM, Markus Karg <markus.karg_at_gmx.net> wrote:
> Wolfgang,
>
> thank you for the link. You are right, @XmlRootElement does not allow
> @XmlJavaTypeAdapter according to the specification. In fact, I wonder why,
> since it works pretty well.
>
My experiments have always shown that the adapter is not called if the
annotated element is indeed used as the document root element.
> About being a root: Due to the schema, <e> *can* be a root, but typically
> it is not (it's one of these flexible "do what you want with this tag"
> schemas that I dislike so much). You wrote it is confusing that it is
> annotated @XmlRootElement. In fact, I wonder why. Maybe I have misunderstood
> the idea of this annotation, but I always thought that it marks an element
> that potentially *could* be a root. Is that wrong? Do I have to remove it
> unless it *must* be a root?
>
Well, if the schema says it can be, then you'll have to follow suit. (But
note my above remark.)
And what do you mean with "strange" combination? I have a schema describing
> the format of a XML file that another software is providing. I am writing a
> software that must read / write that file format. So what is so strange
> about the fact that I may not change the schema? Or what is strange about
> the fact that I want to compare an enum quite as usual using "if (x ==
> e.V_1)" instead of writing "if (x.equals(e.V_1))"?
>
Not being able to change a schema isn't the point. - Given a schema, the
usual procedure is to use xjc to compile it into Java code, and that's it.
So, somewhat unusual is your choice of hand-coding the equivalent Java
classes.
The really strange thing is that the schema appears to map an enumeration to
a choice of elements, using the tag names (v1,...) to represent the
enumeration values. The usual technique is to use a xs:string with a set of
xs:enumeration facets, which xjc would indeed compile into a Java enum
class.
Java programmers (have to) learn that object equality cannot be tested using
==, and presumably they'll have to use equals() for all other XML elements
of that schema. In spite of all your efforts to cover the schema author's
(IMHO: ill-advised) design decision, E is not going to become a proper Java
Enum<?> subclass.
For the Unmarshaller.Listener: As I explained several times, the code is
> called by third parties, so I cannot enforce what you wrote. If one of them
> forgets to register the Unmarshaller.Listener, then my hotline will be
> called. This is costs that I want to prevent if any possible. Hence, a
> selfcontained solution is needed.
>
> I merely mentioned it "for the record". (I do understand that you just
provide an API - although this *might *include wrappers for marshalling and
unmarshalling.)
Cheers
Wolfgang
>
>
> Regards
>
> Markus
>
>
>