cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edwin Quita <edwin.qu...@gmail.com>
Subject Re: My XFire/CXF saga
Date Wed, 11 Mar 2009 11:09:51 GMT
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
<cornel.masson@shazamteam.com> 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
> ______________________________________________________________________
>

Mime
View raw message