CXF configuration ideas

Environment

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

Idea

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.

Spring

XML

Annotation based

Blueprint

CDI

Endpoint