This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • CXF configuration ideas
Skip to end of metadata
Go to start of metadata


CXF is intended to work in a wide range of containers / frameworks:

  • Plain Java
  • Spring XML and annotation based
  • Blueprint
  • JavaEE (CDI)

It for each of the important cases it should be as easy and natural to configure CXF for the developer.

Problem description

Currently CXF provides a lot of integration points with frameworks as well as CXF proprietary ways of configuration.

Out current approach has several drawbacks:

  • Integration with some frameworks creates problems with other frameworks. For example the aries blueprint namespaces make it impossible to use gemini blueprint
  • CXF configuration is often quite unnatural for users of the respective frameworks. For example if you define a Feature using the service loader approach you cannot inject resources into it
  • Using other framework is often difficult as we do not have nice plain java ways to setup e.g. endpoints
  • CXF defines special annotations. These are processed in a CXF proprietary way that does not allow to mix these with annotations of the user framework of choice


The general idea is to step back and keep injection out of CXF as much as possible and instead rely more on the frameworks to do this job. This should make CXF much more embedable and less complex. We still can have some glue code for the frameworks but at as few points as possible.

A good example for this is camel which defines a registry concept that is implemented differently for each framework. In spring it relies on the spring context in blueprint on the blueprint context, in OSGi on services. The camel registry is not perfect but a good step in the right direction.

In the following checpters we should look into the respective frameworks and discuss how CXF integration should work ideally.



Annotation based



Feature definition
public class MyFeature extends AbstractFeature {

Endpoint with inlined injections

public class MyServiceImpl implements MyService {
  @Inject MyRessource res1; // Inject arbitrary user ressources

  @Inject @Named("MyFeature") Feature feature1; // Inject named feature
  @Inject List<Feature> features; // Inject all features known to this context

We might also support some kind of Endpoint description classes to separate endpoint definition from the actual implementation. Not sure how to wire this with CDI. Any ideas?

For the proxy I am not sure which is the best annotation based approach. One idea is to have one or more factories for producers.

Annotation based Proxy definitions
public class MyServiceProducer {

  @Produce MyService createMyService() {
     return new JAXWSProxyFactory("http://myserver:8080/myService");

  @Produce @MyMarker // CDI Qualifiers to distinguish services of the same interface type
  MyService createMyService() {
XML based proxy definition
Annotation based JAXRS Endpoint definition
  • No labels