Thanks for the update. It sounds like good progress.
A few questions:
1) Is there a good reason that the SDO code generator is in the runtime
module? Can we use it without dragging in the CXF runtime?
2) I cannot build the module as either
org.apache.cxf:cxf-parent:pom:2.3.0-SNAPSHOT is not published in Apache
snapshot repo or the pom doesn't have the repo configured.
Thanks,
Raymond
--------------------------------------------------
From: "Daniel Kulp" <[email protected]>
Sent: Friday, July 31, 2009 8:16 AM
To: <[email protected]>
Subject: Re: SDO wsdl2java plugin copied to CXF.....
Just a quick update on this.....
I've updated the SDO stuff in cxf to pull the schemas from the
XmlSchemaCollection we've already parsed and processed. Thus, it doesn't
need to handle imports or wsdl things or catalogs or anything like that as
we've already done it. Thus, that part is now done.
I've also figured out how to get the interfaces and factory classes into
the
ClassCollector. Thus, it's looking pretty good now. Obviously, I need
to
do a lot more testing with more complex scenarios and such, but as a
"base",
it's looking pretty good.
On a side note, we also have a JAX-RS provider working with the SDO
databinding in CXF. :-)
Dan
On Wed July 22 2009 5:20:33 pm Daniel Kulp wrote:
This is mostly to let you know that I've copied the SDO parts (not the
Axiom and DOM stuff) of your project into CXF as part of getting a full
SDO
based databinding working in for CXF. As part of that, I had to update
a
few things so that I could get my basic tests working.
1) ClassCollector - I did have to update the usage of the ClassCollector
to
record SOMETHING. Right now, it does record the impls, but doesn't
record
the actual interfaces or the SdoFactory and other things. That really
needs some work or we'll hit some nasty cases where types are overwritten
by JAX-WS artifacts and such.
2) "dynamic" binding - when generating code for dynamic, I made it
generate
"DataObject" for the types where appropriate. That allowed the
generated
code to actually compile. I'm not 100% sure it's correct, but it works.
My round trip tests even work. :-)
One issue I've discovered is that feeding the wsdl into the sdo code
generator really doesn't work very well if the schemas are really in a
wsdl
that the original wsdl imports. The code generator doesn't generate
anything. It looks like the code generator doesn't follow wsdl imports
at
all. Thus, there are a couple options:
1) Update the sdo code generator to follow wsdl imports. I don't know
enough about the sdo code generator to know how hard that is to do.
2) Grab the schemas out of the ToolContext and feed them in directly.
This
will be slightly complicated with imports and such, but nothing too
major.
This is what we do for JAXB. This has a slight advantage in that urls
and
such would already be resolved through the catalogs and such.
Another note: the code the sdo code generator generates produces a BUNCH
of
warnings in eclipse. Would people object to updating the sdo code
generator to produce code with less warnings? I'd ALSO like to add a
"-java5" flag or something that would allow typing the lists
(List<String>)
and possibly add a @SuppressWarnings("unchecked") in the one method in
the
factory that has a checked issues, but I'm not sure how bad that would
be
from a spec standpoint.
Anyway, code is at:
http://svn.apache.org/repos/asf/cxf/trunk/rt/databinding/sdo/
I have server side round trips (soap comes in, sdo objects created, impl
called, response sent back via soap) working for both the static and
dynamic cases. Your plugin was definitely a huge help getting that
working.
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
