JDK 1.6 incorporates the JAXB reference implementation. However, it incorporates an old version of the RI. CXF does not support this version. As of 1.6_04, this is easy to deal with: you must put the versions of JAXB RI (the 'impl' and 'xjc' jars) that we include with CXF in your classpath. As of this writing, these are version 2.1.6.
No. Many of the technologies that CXF is based on require JDK 1.5. JAX-WS, JAXB, &cetra all require JDK 1.5 feastures such as generics and annotations.
Yes. CXF supports axis2-saaj version 1.4.1 as an alternative. This can make life easier if you
use a non-Sun JDK.
Progress FUSE Services Framework is based on Apache CXF to deliver a platform for developing rich service oriented applications.
Consider what Red Hat has done with Linux. Anyone can build their own Linux distribution (http://www.linuxfromscratch.org/) but few people care to do this because of the effort involved in the maintenance, support, testing, validation, etc. of such an effort. Red Hat provides the world with an easily installable Linux distribution with much value added and enterprise level services and support. FUSE is very similar to RedHat Linux insomuch as adding value to quality open source software (Apache ActiveMQ, Apache Camel, Apache Derby, Apache ServiceMix, Jetty, etc.) and providing services, support and training for a vetted version of the software.
For some additional insight into the FUSE model and how it works, see Bruce Snyder's blog entry entitled The IONA FUSE Model and It's Benefits to the Community. You can also find additional information about FUSE Services Framework and the FUSESource community at "Why join our community".
Official answer: The JAX-WS spec (specifically section 3.6.1) mandates that it be generated this way. To customize the name, you have to use an @WebParam(name = "blah") annotation to specify better names. (You can use @WebResult for the return value, but you'll only see the results if you look at the XML.)
Reason: One of the mysteries of java is that abstract methods (and thus interface methods) do NOT get their parameter names compiled into them even with debug info. Thus, when the service model is built from an interface, there is no way to determine the names that were using in the original code.
If the service is built from a concrete class (instead of an interface) AND the class was compiled with debug info, we can get the parameter names. The simple frontend does this. However, this could cause potential problems. For example, when you go from developement to production, you may turn off debug information (remove -g from javac flags) and suddenly the application may break since the generated wsdl (and thus expect soap messages) would change. Thus, the JAX-WS spec writers went the safe route and mandate that you have to use the @WebParam annotations to specify the more descriptive names.
There are several ways to do this depending on how your project is written (code first or wsdl first) and requirements such as portability.
List<Header> headers = new ArrayList<Header>(); Header dummyHeader = new Header(new QName("uri:org.apache.cxf", "dummy"), "decapitated", new JAXBDataBinding(String.class)); headers.add(dummyHeader); //server side: context.getMessageContext().put(Header.HEADER_LIST, headers); //client side: ((BindingProvider)proxy).getRequestContext().put(Header.HEADER_LIST, headers); |
For the client side
<jaxws:client name="{http://apache.org/hello_world_soap_http}SoapPort" createdFromAPI="true"> <jaxws:properties> <entry key="schema-validation-enabled" value="true" /> </jaxws:properties> </jaxws:client> |
You may also do this programmatically:
((BindingProvider)port).getRequestContext().put("schema-validation-enabled", "true"); |
For the server side
<jaxws:endpoint name="{http://apache.org/hello_world_soap_http}SoapPort" wsdlLocation="wsdl/hello_world.wsdl" createdFromAPI="true"> <jaxws:properties> <entry key="schema-validation-enabled" value="true" /> </jaxws:properties> </jaxws:endpoint> |
Starting with CXF 2.3 you have the additional option of using the org.apache.cxf.annotations.SchemaValidation annotation.
Official JAX-WS answer: No. According to the JAX-WS spec, the client proxies are NOT thread safe. To write portable code, you should treat them as non-thread safe and synchronize access or use a pool of instances or similar.
CXF answer: CXF proxies are thread safe for MANY use cases. The exceptions are:
((BindingProvider)proxy).getRequestContext().put("thread.local.request.context", "true"); |
For the conduit issues, you COULD install a new ConduitSelector that uses a thread local or similar. That's a bit complex though.
For most "simple" use cases, you can use CXF proxies on multiple threads. The above outlines the workarounds for the others.
Reason: When using Spring AOP, spring injects a proxy to the bean into CXF instead of the actual bean. The Proxy does not have the annotations on it (like the @WebService annotation) so we cannot query the information directly from the object like we can in the non-AOP case. The "fix" is to also specify the actual serviceClass of the object in the spring config:
<jaxws:server id="myService" serviceClass="my.package.MyServiceImpl" serviceBean="#myServiceImpl" address="/MyService" /> |
or:
<jaxws:endpoint id="myService" implementorClass="my.package.MyServiceImpl" implementor="#myServiceImpl" address="/MyService" /> |