You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Dain Sundstrom <da...@iq80.com> on 2007/06/26 23:23:12 UTC
Jaxb2 rocks!
I just committed the last changes to convert our old Castor tree to
Jaxb2, and the resulting code is wonderful. Take a look if you have
some time org.apache.openejb.config.sys. Here are some notes on the
conversion:
* I started with a generated codebase using the following command:
$ ls
activation.jar jaxb-api.jar jaxb-impl.jar jaxb-
xjc.jar jsr173_1.0_api.jar
$ java -jar jaxb-xjc.jar openejb.xsd
* The generated classes are very clean and easy to modify by hand as
they don't have any generated marshaling logic. This does mean that
the startup is a bit slower due to the need to generate this at
runtime, but our schemas are tiny.
* Most of the elements in the OpenEJB tree implement the Service
interface, and actually have the same implementation code. I was
able to create (extract) an AbstractService that each of services
extend. Inheritance just worked... no magic.
* I was able to convert the String "content" property in our services
directly to a Properties object at marshall time with the
PropertiesAdapter I wrote. Jaxb has a very clean properties adapter
system that lets you convert any type the XML system understands to a
non-annotated java type.
BTW, hats off to the Castor team! Castor carried us for a long time,
and Jaxb2 was vastly influenced by the Castor team (it is effectly
Castor 2.0).
-dain
Re: Jaxb2 rocks!
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Nice. Anyway, it doesn't seem like OpenEJB is having that problem, so
hopefully it will all just be a bad memory by the time I need to
generate another SOAP client. :)
Thanks,
Aaron
On 7/18/07, Dain Sundstrom <da...@iq80.com> wrote:
> Aaron,
>
> I'm reading more JaxB docs today, and found a very good explanation
> (http://weblogs.java.net/blog/kohsuke/archive/2006/03/
> why_does_jaxb_p.html.) of why you were seeing JAXBElements and how to
> stop JaxB from generating. Basically, you need to tell JaxB that the
> schema you are compiling is stand alone and specifically, won't be
> referenced later by another schema. Then JaxB can assume it sees all
> possible types and generates more tight Java code.
>
> -dain
>
> On Jun 27, 2007, at 8:35 AM, Dain Sundstrom wrote:
>
> > Nope. I think there were some bugs in the early version of JaxB
> > that did that. I'm using:
> >
> > $ java -jar jaxb-xjc.jar -version
> > xjc version "2.0.5-b02-fcs"
> > JavaTM Architecture for XML Binding(JAXB) Reference Implementation,
> > (build 2.0.5-b02-fcs)
> >
> > David also mentioned that inheritance didn't used to work, but it
> > worked perfectly for me. I guess it was another bug they fixed.
> >
> > -dain
> >
> > On Jun 26, 2007, at 6:26 PM, Aaron Mulder wrote:
> >
> >> Did you run into anything that became the type JAXBElement<String>?
> >> That was my big issue with JAXB2. OK, this is at best loosely
> >> related, but... I used XFire on a WSDL and some of the String
> >> properties that I would have expected to see as setFoo(String) became
> >> setFoo(JAXBElement<String>) which was really annoying to work with.
> >> Dan said there was at least a workaround for JAXB 2.1 I think.
> >>
> >> Thanks,
> >> Aaron
> >>
> >> On 6/26/07, Dain Sundstrom <da...@iq80.com> wrote:
> >>> I just committed the last changes to convert our old Castor tree to
> >>> Jaxb2, and the resulting code is wonderful. Take a look if you have
> >>> some time org.apache.openejb.config.sys. Here are some notes on the
> >>> conversion:
> >>>
> >>> * I started with a generated codebase using the following command:
> >>>
> >>> $ ls
> >>> activation.jar jaxb-api.jar jaxb-impl.jar jaxb-
> >>> xjc.jar jsr173_1.0_api.jar
> >>>
> >>> $ java -jar jaxb-xjc.jar openejb.xsd
> >>>
> >>> * The generated classes are very clean and easy to modify by hand as
> >>> they don't have any generated marshaling logic. This does mean that
> >>> the startup is a bit slower due to the need to generate this at
> >>> runtime, but our schemas are tiny.
> >>>
> >>> * Most of the elements in the OpenEJB tree implement the Service
> >>> interface, and actually have the same implementation code. I was
> >>> able to create (extract) an AbstractService that each of services
> >>> extend. Inheritance just worked... no magic.
> >>>
> >>> * I was able to convert the String "content" property in our
> >>> services
> >>> directly to a Properties object at marshall time with the
> >>> PropertiesAdapter I wrote. Jaxb has a very clean properties adapter
> >>> system that lets you convert any type the XML system understands
> >>> to a
> >>> non-annotated java type.
> >>>
> >>> BTW, hats off to the Castor team! Castor carried us for a long
> >>> time,
> >>> and Jaxb2 was vastly influenced by the Castor team (it is effectly
> >>> Castor 2.0).
> >>>
> >>> -dain
> >>>
> >>>
> >
>
>
>
Re: Jaxb2 rocks!
Posted by Dain Sundstrom <da...@iq80.com>.
Aaron,
I'm reading more JaxB docs today, and found a very good explanation
(http://weblogs.java.net/blog/kohsuke/archive/2006/03/
why_does_jaxb_p.html.) of why you were seeing JAXBElements and how to
stop JaxB from generating. Basically, you need to tell JaxB that the
schema you are compiling is stand alone and specifically, won't be
referenced later by another schema. Then JaxB can assume it sees all
possible types and generates more tight Java code.
-dain
On Jun 27, 2007, at 8:35 AM, Dain Sundstrom wrote:
> Nope. I think there were some bugs in the early version of JaxB
> that did that. I'm using:
>
> $ java -jar jaxb-xjc.jar -version
> xjc version "2.0.5-b02-fcs"
> JavaTM Architecture for XML Binding(JAXB) Reference Implementation,
> (build 2.0.5-b02-fcs)
>
> David also mentioned that inheritance didn't used to work, but it
> worked perfectly for me. I guess it was another bug they fixed.
>
> -dain
>
> On Jun 26, 2007, at 6:26 PM, Aaron Mulder wrote:
>
>> Did you run into anything that became the type JAXBElement<String>?
>> That was my big issue with JAXB2. OK, this is at best loosely
>> related, but... I used XFire on a WSDL and some of the String
>> properties that I would have expected to see as setFoo(String) became
>> setFoo(JAXBElement<String>) which was really annoying to work with.
>> Dan said there was at least a workaround for JAXB 2.1 I think.
>>
>> Thanks,
>> Aaron
>>
>> On 6/26/07, Dain Sundstrom <da...@iq80.com> wrote:
>>> I just committed the last changes to convert our old Castor tree to
>>> Jaxb2, and the resulting code is wonderful. Take a look if you have
>>> some time org.apache.openejb.config.sys. Here are some notes on the
>>> conversion:
>>>
>>> * I started with a generated codebase using the following command:
>>>
>>> $ ls
>>> activation.jar jaxb-api.jar jaxb-impl.jar jaxb-
>>> xjc.jar jsr173_1.0_api.jar
>>>
>>> $ java -jar jaxb-xjc.jar openejb.xsd
>>>
>>> * The generated classes are very clean and easy to modify by hand as
>>> they don't have any generated marshaling logic. This does mean that
>>> the startup is a bit slower due to the need to generate this at
>>> runtime, but our schemas are tiny.
>>>
>>> * Most of the elements in the OpenEJB tree implement the Service
>>> interface, and actually have the same implementation code. I was
>>> able to create (extract) an AbstractService that each of services
>>> extend. Inheritance just worked... no magic.
>>>
>>> * I was able to convert the String "content" property in our
>>> services
>>> directly to a Properties object at marshall time with the
>>> PropertiesAdapter I wrote. Jaxb has a very clean properties adapter
>>> system that lets you convert any type the XML system understands
>>> to a
>>> non-annotated java type.
>>>
>>> BTW, hats off to the Castor team! Castor carried us for a long
>>> time,
>>> and Jaxb2 was vastly influenced by the Castor team (it is effectly
>>> Castor 2.0).
>>>
>>> -dain
>>>
>>>
>
Re: Jaxb2 rocks!
Posted by Dain Sundstrom <da...@iq80.com>.
Nope. I think there were some bugs in the early version of JaxB that
did that. I'm using:
$ java -jar jaxb-xjc.jar -version
xjc version "2.0.5-b02-fcs"
JavaTM Architecture for XML Binding(JAXB) Reference Implementation,
(build 2.0.5-b02-fcs)
David also mentioned that inheritance didn't used to work, but it
worked perfectly for me. I guess it was another bug they fixed.
-dain
On Jun 26, 2007, at 6:26 PM, Aaron Mulder wrote:
> Did you run into anything that became the type JAXBElement<String>?
> That was my big issue with JAXB2. OK, this is at best loosely
> related, but... I used XFire on a WSDL and some of the String
> properties that I would have expected to see as setFoo(String) became
> setFoo(JAXBElement<String>) which was really annoying to work with.
> Dan said there was at least a workaround for JAXB 2.1 I think.
>
> Thanks,
> Aaron
>
> On 6/26/07, Dain Sundstrom <da...@iq80.com> wrote:
>> I just committed the last changes to convert our old Castor tree to
>> Jaxb2, and the resulting code is wonderful. Take a look if you have
>> some time org.apache.openejb.config.sys. Here are some notes on the
>> conversion:
>>
>> * I started with a generated codebase using the following command:
>>
>> $ ls
>> activation.jar jaxb-api.jar jaxb-impl.jar jaxb-
>> xjc.jar jsr173_1.0_api.jar
>>
>> $ java -jar jaxb-xjc.jar openejb.xsd
>>
>> * The generated classes are very clean and easy to modify by hand as
>> they don't have any generated marshaling logic. This does mean that
>> the startup is a bit slower due to the need to generate this at
>> runtime, but our schemas are tiny.
>>
>> * Most of the elements in the OpenEJB tree implement the Service
>> interface, and actually have the same implementation code. I was
>> able to create (extract) an AbstractService that each of services
>> extend. Inheritance just worked... no magic.
>>
>> * I was able to convert the String "content" property in our services
>> directly to a Properties object at marshall time with the
>> PropertiesAdapter I wrote. Jaxb has a very clean properties adapter
>> system that lets you convert any type the XML system understands to a
>> non-annotated java type.
>>
>> BTW, hats off to the Castor team! Castor carried us for a long time,
>> and Jaxb2 was vastly influenced by the Castor team (it is effectly
>> Castor 2.0).
>>
>> -dain
>>
>>
Re: Jaxb2 rocks!
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Did you run into anything that became the type JAXBElement<String>?
That was my big issue with JAXB2. OK, this is at best loosely
related, but... I used XFire on a WSDL and some of the String
properties that I would have expected to see as setFoo(String) became
setFoo(JAXBElement<String>) which was really annoying to work with.
Dan said there was at least a workaround for JAXB 2.1 I think.
Thanks,
Aaron
On 6/26/07, Dain Sundstrom <da...@iq80.com> wrote:
> I just committed the last changes to convert our old Castor tree to
> Jaxb2, and the resulting code is wonderful. Take a look if you have
> some time org.apache.openejb.config.sys. Here are some notes on the
> conversion:
>
> * I started with a generated codebase using the following command:
>
> $ ls
> activation.jar jaxb-api.jar jaxb-impl.jar jaxb-
> xjc.jar jsr173_1.0_api.jar
>
> $ java -jar jaxb-xjc.jar openejb.xsd
>
> * The generated classes are very clean and easy to modify by hand as
> they don't have any generated marshaling logic. This does mean that
> the startup is a bit slower due to the need to generate this at
> runtime, but our schemas are tiny.
>
> * Most of the elements in the OpenEJB tree implement the Service
> interface, and actually have the same implementation code. I was
> able to create (extract) an AbstractService that each of services
> extend. Inheritance just worked... no magic.
>
> * I was able to convert the String "content" property in our services
> directly to a Properties object at marshall time with the
> PropertiesAdapter I wrote. Jaxb has a very clean properties adapter
> system that lets you convert any type the XML system understands to a
> non-annotated java type.
>
> BTW, hats off to the Castor team! Castor carried us for a long time,
> and Jaxb2 was vastly influenced by the Castor team (it is effectly
> Castor 2.0).
>
> -dain
>
>
Re: Jaxb2 rocks!
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 6/26/07, Dain Sundstrom <da...@iq80.com> wrote:
> I just committed the last changes to convert our old Castor tree to
> Jaxb2, and the resulting code is wonderful. Take a look if you have
> some time org.apache.openejb.config.sys. Here are some notes on the
> conversion:
Kudos to you. I've been thinking about jaxb2 and having seen your fun
while doing the conversion I can't resist to look at it.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Jaxb2 rocks!
Posted by Karan Malhi <ka...@gmail.com>.
Dain,
This is beautiful. This should definitely go to the documentation.
Thanks for sharing this info
I also saw quite a few postings from you in the mail archives which
were very informative. In case you remember something at the top of
your head, which you think could go into docs, please let me know.
On 6/26/07, Dain Sundstrom <da...@iq80.com> wrote:
> I just committed the last changes to convert our old Castor tree to
> Jaxb2, and the resulting code is wonderful. Take a look if you have
> some time org.apache.openejb.config.sys. Here are some notes on the
> conversion:
>
> * I started with a generated codebase using the following command:
>
> $ ls
> activation.jar jaxb-api.jar jaxb-impl.jar jaxb-
> xjc.jar jsr173_1.0_api.jar
>
> $ java -jar jaxb-xjc.jar openejb.xsd
>
> * The generated classes are very clean and easy to modify by hand as
> they don't have any generated marshaling logic. This does mean that
> the startup is a bit slower due to the need to generate this at
> runtime, but our schemas are tiny.
>
> * Most of the elements in the OpenEJB tree implement the Service
> interface, and actually have the same implementation code. I was
> able to create (extract) an AbstractService that each of services
> extend. Inheritance just worked... no magic.
>
> * I was able to convert the String "content" property in our services
> directly to a Properties object at marshall time with the
> PropertiesAdapter I wrote. Jaxb has a very clean properties adapter
> system that lets you convert any type the XML system understands to a
> non-annotated java type.
>
> BTW, hats off to the Castor team! Castor carried us for a long time,
> and Jaxb2 was vastly influenced by the Castor team (it is effectly
> Castor 2.0).
>
> -dain
>
--
Karan Singh Malhi