Brian Pontarelli wrote:
>> <xs:complexType name="fooBar">
>> ...
>> <xs:element name="servlet">
>> <xs:annotation><xs:appinfo>
>> <property name="servlets" type="map" />
>> </
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="servlet-name" type="xs:string"/>
>> <xs:annotation><xs:appinfo>
>> <key />
>> </
>> <xs:element name="servlet-class" type="xs:string"/>
>>
>> to produce something like:
>>
>> class FooBar {
>> Map<String,Servlet> servlets;
>>
>> class Servlet {
>> String name;
>> String class;
>> }
>
> This would work fine, but at the same time, I can't ship a schema with
> jaxb elements in it so it must be configurable outside of the schema as
> well as inside the class.
Oh yes, of course. The external binding file support layer is orthogonal
to all these discussions. Any extensions we define, even if those are
defined in the plug-ins, it will be automatically supported in the
external binding files.
>> Really? Thanks! I'll ask the management to see if we can publish the
>> javadoc of the RI. It has enough pluggability layer in place already
>> to allow someone to work on something like this. But for that I'll
>> have to work with legendary Sun lawyers once again...
>>
>> I think the map support would be useful without a hashCode/equal
>> implementation. The above servlet sample is one such example.
>
> Agreed, but if the Map support is blown out to support complex elements
> as keys, then it is required. I could actualy see that support being
> highly desirable. Consider this snippet:
Yep. I agree. And I'm now counting on you to write such a plug-in!
>
> <lastTripForEachUser>
> <itinerary>
> <user email="foo_at_bar.com" name="John Doe" age="29"/>
> <record>
> ...
> </record>
> </itinerary>
> ...
> </>
>
> This could look like this:
>
> public class LastTripForEachUser {
> private Map<User, Itinerary> itinerary;
> }
Exactly.
>> I guess the point I was trying to make is that if you have a need to
>> build a in-memory representation very different from the on-the-wire
>> format, you can always use ObjectLifecycle or @XmlJavaTypeAdapter.
>>
>> For your custom class, I think actually you can already do this today.
>> I agree that a better out-of-box binding would be highly desirable,
>> and I agree that supporting such code generation from a schema would
>> be also nice to have.
>
> If there is already annotation support for this than adding it to the
> XJC is just secondary. I'm not in favor of using the lifecycle support,
> but if necessary than I can. I'd much rather have a clean POJO
> implementation without requiring additional support classes.
I understand.
> How is that example of JAXB 2.0 using custom classes, external binding
> definitions and all that advanced stuff coming? ;) I've very anxious to
> check it out!
Yesterday I posted a blog explaining the basics of "persisting your
classes" [1]
I'll write another one to explain how to use an adapter to support
different in-memory layout.
[1]
http://weblogs.java.net/blog/kohsuke/archive/2005/02/using_jaxb_20_t.html
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com