You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Frequently Asked Questions

General

Apache Incubator and Graduation - When is CXF going to graduate? Is the code "production ready?" Etc....

The Apache Incubator is the entity designed to get projects up to speed with the "Apache" way of doing things. A project being in the incubator in no way reflects the quality of the code. There is some very good code in the incubator projects. Incubation status just means that the incubator PMC (or the project itself) doesn't feel that the project is quite ready to be a full Apache project. Some of the reasons:

  1. Legal issues - all code has to be Apache licensed and downloadable packages need to meet very strict Apache guidelines and such. CXF is fully compliant in this respect.
  2. Community issues - Is the project acting like an apache community? Are they voting in new commiters? Are decisions and discussions done on the mailing lists? Are releases made per Apache guidelines? etc... Are new people encouraged to contribute to discussions and code?
  3. Community Diversity - Apache wants projects to have a diverse community with contributors coming from a wide variety of backgrounds, companies, etc... Thus, if a company withdraws it's support, the project will live on. (This is one of CXF's main issues. The CXF committer list is very heavily IONA-weighted.)

Being in the incubator is not a "bad" thing. If the project is active, its members are most likely trying to "graduate" out of the incubator and are working on it. It just takes time. I think the average project spends about 1.5 years in the incubator. The project just needs to perform in such a way that the Apache Incubator PMC/mentors feel that the project is operating in the appropriate "Apache" way, has learned and demonstrated the proper Apache processes, etc...

That said, a project in the incubator isn't guaranteed to graduate. There have been several projects that have "died" in the incubator. They were a good idea when they were started, but couldn't really generate a community around the code or the main company starting it withdrew the support, etc...

The questions you need to ask yourself are: Do you feel comfortable with the level of support from the current CXF community? Do you feel we will still be here in 6 months? 1 year?

Better yet, ask yourself, 'Could I join the community, contribute to the code, and become a committer?' The larger and more diverse our community of committers, the sooner (certis paribus) we will graduate.

Can CXF run on JDK 1.4?

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.

JAX-WS Related

The parts in my generated wsdl have names of the form "arg0", "arg1", ... Why don't the parts (and Java generated from them) use the nice parameter names I typed into the interface definition?

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.

How can I add soap headers to the request/response?

There are several ways to do this depending on how your project is written (code first or wsdl first) and requirements such a portability.

  1. The "JAX-WS" standard way to do this is to write a SOAP Handler that will add the headers to the SOAP message and register the handler on the client/server. This is completely portable from jax-ws vendor to vendor, but is also more difficult and can have performance implications. You have to handle the conversion of the JAXB objects to XML yourself. It involves having the entire soap message in a DOM which breaks streaming. Requires more memory. etc... However, it doesn't require any changes to wsdl or SEI interfaces.
  2. JAX-WS standard "java first" way: if doing java first development, you can just add an extra parameter to the method and annotate it with @WebParam(header = true). If it's a response header, make it a Holder and add the mode = Mode.OUT to @WebParam.
  3. wsdl first way: you can add elements to the message in the wsdl and then mark them as soap:headers in the soap:binding section of the wsdl. The wsdl2java tool will generate the @WebParam(header = true) annotations as above. With CXF, you can also put the headers in their own message (not the same message as the request/response) and mark them as headers in the soap:binding, but you will need to pass the -exsh true flag to wsdl2java to get the paramters generated. This is not portable to other jax-ws providers. Processing headers from other messages it optional in the jaxws spec.
  4. CXF proprietary way: In the context (BindingProvider.getRequestContext() on client, WebServiceContext on server), you can add a List<org.apache.cxf.headers.Header> with the key Header.HEADER_LIST. The headers in the list are streamed at the appropriate time to the wire according to the databinding object found in the Header object. Like option 1, this doesn't require changes to wsdl or method signatures. However, it's much faster as it doesn't break streaming and the memory overhead is less.

Spring Related

When using Spring AOP to enable things like transactions and security, the generated WSDL is very messed up with wrong namespaces, part names, etc...

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" />
  • No labels