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
