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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>
>>>
>
