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

Compare with Current View Page History

« Previous Version 3 Next »

Frequently Asked Questions

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. It just means that the
incubator people (or the project itself) doesn't feel the project is
quite ready to be a full Apache project. There can be a variety of
reasons:

  1. Legal issues - all code has to be Apache licensed and downloadable
    packages need to meet very strict Apache guidelines and such.
  1. 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?
  1. 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.)
  1. many more....

Basically, being in the incubator is not really a "bad" thing. If the
project is active, they 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, maybe longer.
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? etc...

JAX-WS Related

The parts in my generated wsdl are names "arg0", "arg1", etc... Why can't it generate better names?

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 (@WebResult for the return value) to specify better names.

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.

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