CXF's wsdl2java tool does not appear to support the Provider/Dispatch
style code generation to support document handling. If i pick up
only the invoke then I am required to hand code (for instance) the
distinction between the 4 operations of the service.
SWDP's RESTful tooling supports a
As far as for CXF 2.0 release, there was a discussion on mailing list
[1] a couple weeks ago. According to my knowledge, most items discussed
on that mail have been completed now, and I think dev-team is preparing
for a 2.0 release now. Hopefully, we will see a 2.0 final release this
week or
I get another error now which I can't understand.
My server needs to talk to another service in order to initialise itself. When
it tries to talk to the other service it gives me an error based on my
service.xml.
I guessing that it has nothing to do with who I'm talking to but with creating
Now that I read my own email, (uggg, mistake) just let me give you the
whole schema location
attribute.
xsi:schemaLocation=
http://cxf.apache.org/transports/http-jetty/configuration
http://cxf.apache.org/schemas/configuration/http-jetty.xsd
Hi
Can't resist :-)
God I love XML! They say it's flexible!
It's flexible. All depends on how it's used and in what contexts it's used.
It's good for ensuring the interoperability on the wire but may or may not be
the best fit for doing the configuration.
Cheers, Sergey
- Original
Sergey Beryozkin wrote:
Hi
This is a bit scary :-)
I think I can remember a catalog solution being discussed. so that this
xsi:location can be dropped, is it feasible to apply that catalog solution
somehow ?
I'm no expert on this, but things like META-INF/spring.schemas is sort
of a
