hi Cornel,
i have not encountered any problems with CXF in terms of using wsdl2java
here's a sample plugin configuration in my pom.xml file
<!-- Apache CXF Code Generator -->
<!-- Used for generating web service client stubs in
Java -->
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-codegen-plugin</artifactId>
<version>2.0.6</version>
<executions>
<execution>
<id>generate-sources-email</id>
<phase>generate-sources</phase>
<configuration>
<!-- target folder for
generated java sources -->
<sourceRoot>
${basedir}/target/generated/src/main/java
</sourceRoot>
<wsdlOptions>
<wsdlOption>
<wsdl>
${wsdl.sourceDirectory}/HelloWorldCopy.wsdl
</wsdl>
</wsdlOption>
</wsdlOptions>
</configuration>
<goals>
<goal>wsdl2java</goal>
</goals>
</execution>
</executions>
</plugin>
and add these to your dependencies section
<!-- Apache CXF JAX-WS Impl -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>2.0.6</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>2.0.6</version>
</dependency>
plus a repository for JAXB
<repositories>
<!-- for JAXB-Impl dependencies -->
<!-- JAX-WS uses JAXB for marshalling and unmarshalling
xml/javabeans -->
<repository>
<id>java.net</id>
<url>http://download.java.net/maven/1/</url>
<layout>legacy</layout>
</repository>
</repositories>
that should work.
HTH,
edwin
On Wed, Mar 11, 2009 at 10:47 AM, Cornel Masson
<[email protected]> wrote:
> Hi
>
> I write this not as a flame, but as honest feedback, in the hope that there
> are perhaps solutions to some of these problems...
>
> We are replacing our core system with a solution that uses SOAP to talk to a
> gSOAP server. We were recommended XFire (this was before CXF existed), since
> it was supposed to be lean, mean and really fast, and much easier to use
> than the mainstream Java SOAP offerings. I only had to build a SOAP client -
> no server - and used the standard Aegis/JAX-WS/JAXB setup.
>
> Everything went fine through development and testing, until the first day in
> production: suddenly there were spurious SOAP errors. We had to roll back.
> Further investigation pointed to the XFire SOAP client not being
> *thread-safe* (the Test Dept's tests did not have high enough concurrency,
> hence the production embarassment). It looked like XFire (or a sub-module)
> was garbling some SOAP request (see example below: it looks like two threads
> are writing to the same output stream??):
>
> <soap:Body xmmllnnss::nnss11==""uurrnn::sshhaazzaamm--ccoomm...
>
>
> After much googling and fiddling I got no result, so I decided that the best
> way forward was to replace XFire. Hoping that CXF would have fixed all such
> problems, I ported to it. Hmm. Firstly, I couldn't generate the Java classes
> because of a NullPointer in wsdl2java (seen posts on forum, but unable to
> fix - XFire generated fine from same WSDL). I then tried various manual
> options from the CXF docs, e.g. using a <jaxws:client>, a more manual
> JaxWsProxy, etc., but a nasty 'feature' kept tripping me up: if a method
> name ends in "Async", CXF assumes it is using *async* SOAP semantics. Is
> this in the SOAP standard? It so happens that two of our methods end in
> "Async", but require normal handling. I finally had to side-step the
> abstractions and hand-craft something around the CXF Client directly. Great:
> so far so good.
>
> Now for the acid test: our new, aggressive mult-threaded test suite. Boom!
> Same sort of problems as XFire. I made a list of the kind of errors we're
> seeing under load (see end of message). As far as I'm aware we don't see any
> of these errors in single-threaded tests. I estimated that it would be
> easier to wrap CXF in a thread-safe facade, than to replace it, so I
> implemented a pool of CXF Clients. That reduced the error frequency, but
> didn't eliminate it. Up against the wall by this stage, with Management
> looming, I implemented a *retry* mechanism, i.e. if CXF throws a
> org.apache.cxf.binding.soap.SoapFault or org.apache.cxf.interceptor.Fault,
> and the error looks like something transient, wait a while and retry. With
> the pool of CXF clients, and 1 retry on SOAP error, all our requests now
> finally succeed.
>
> So: what now? My workarounds are just that: workarounds to get a first
> version running in production. I wouldn't want to leave it like that. So,
> the question is:
>
> 1. Am I stupid or did I miss something fundamental about CXF (this is my 1st
> SOAP project, so I'm no SOAP expert), or...
> 2. Are there significant thread-safety issues in CXF?
>
> Any comments are welcome :)
>
> Thanks
> Cornel
>
>
> SOAP errors
> --------------
>
> org.apache.cxf.binding.soap.SoapFault: Validation constraint violation: tag
> name or namespace mismatch in element <RetriveRecognitionAsyncRequest>
> org.apache.cxf.binding.soap.SoapFault: Validation constraint violation: tag
> name or namespace mismatch in element <soap:Body<soap:Envelope>)
>
> org.apache.cxf.binding.soap.SoapFault: Method 'soap:Envelope' not
> implemented: method name or namespace not recognized
> org.apache.cxf.binding.soap.SoapFault: Method '' not implemented: method
> name or namespace not recognized
>
> org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter
>
> java.lang.IllegalStateException: Already connected
>
> org.apache.cxf.interceptor.Fault: Marshalling Error: Can't set streaming
> mode: already connected
>
> org.apache.cxf.interceptor.Fault: Response was of unexpected text/html
> ContentType. Incoming portion of HTML stream: <html><body>...
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
