users@jaxb.java.net

Re: Jaxb, problems without solutions ?

From: Aleksei Valikov <valikov_at_gmx.net>
Date: Fri, 1 Aug 2008 15:26:46 +0200

Hi.

> Ok I get it, folder : generated-sources and in the jar.
> Thoses are the default xjc classes. I dont have any interest in them.

I didn't actually meant that you have to use these classes as is. I
just wanted to let you know that there's such a project and maybe
there are few ideas you may find handy there. For instance, versioning
using the package names. Or dependencies between different
specifications and so on.

> Perhaps I can explain a bit more my problem.
> I'm a developper on GeoTools and we already have style/sld classes.

Cool, we use GeoTools a lot.

> Thoses classes implement GeoAPI interfaces which are a mix of GIS
> specification (ISO and OGC) so our style classes doesnt match the
> structure of the xml.
>
> I tryed to use adapters and dummy classes but with only one result :
> polluting the classes with methods, constructors, annotations, breaking
> thread safety (no more immutable objects) and so on ...
>
> A solution would be to proxy our classes with the default xjc classes
> but it would be really slow and would only work one way (marshelling) .

From the questions you posted I guess you actually have two problems:

1. Your class structures don't map 1:1 onto target XML using JAXB.
That's why you need adapters and stuff.
2. You may need to map your objects onto different target XML (XML of
different schema versions/namespaces).

If these considerations are true then it seems that "XMLizability" is
not the property of your classes and you can't solve it with JAXB
annotations. If you define object/XML mappings with annotations then
this mapping is the integral part of the class and this allows little
of the flexibility you need.

I really don't know what would be here the best approach. Clearly,
Object/XML mappings must be defined externally, not in the classes
themselves. Theoretically you could define JAXB mappings in classpath
resources, but this does not solve the (1) problem.

Other possibilities:
* Write converters your classes <-> JAXB classes, schema-derived.
* Use another tool which provides more flexible mapping definitions.

> May I ask how do you (I your work) use the resulting xjc classes ?

We use these classes to parse XML into object structures. These object
structures carry no business methods (no behavior, unlie your case),
they are either passed into some business methods or used as state
objects in more complex classes (which introduce some business
behaviour).

(Not sure if it's clear.)

Bye.
/lexi