Skip to end of metadata
Go to start of metadata

As detailed in my last article I think the current CXF configuration style has it´s problems. To provide people with a short time solution I have described how to use the Camel transport together with Camel´s JMS transport. After my article there was a discussion on the CXF dev mailing list on better JMS support for CXF. The agreement was that CXF should not depend on Camel for JMS and that the JMS config for CXF should be improved.In this article I will propose an alternative configuration style for JMS (and perhaps also other transports). The style is quite similar to Camel´s style and tries to bring the positive aspects of the Camel transports to CXF.


I have started by defining some goals that are important to achieve for the new configuration and implementation. Of course this is only my opinion. I would be very interested in what goals you would like to see implemented.

  • Focus more on dependency injection. Do less in the JMSConduit
  • Allow injection of the ConnectionFactory. So it can be provided directly from a spring bean or via a spring JNDI lookup
  • Allow setting of parameters via ProperyPlaceholderConfigurer
  • Avoid coupling the Conduit to the Client by endpoint name. Instead set the config as property
  • Allow setting of Transport parameters from the address property of the Client or Endpoint
  • Support declarative transactions using Springs JMS support (This is mainly an implementation issue)

Client / Endpoint config

The basis will be as before the Client or Endpoint config. This is extended by one new property transportConfig.


In this sample config we reference the bean jmsConf1 as transportConfig. So all settings in this bean will be the defaults. The url after jms:// is implicit set as the parameter targetDestinationName.

Then each parameter from the address overwrites a property of the JMSConfig. So you can define defaults in the JMSConfig and still do special settings for the Endpoint using the URL. Camel has a nice Tool to extract such config info from a string like address and configure a bean with it using reflection. Setting parameters in this way has it´s drawbacks in transports where the parameters are part of the real URL. I am not yet sure how this can be avoided. Setting the parameters from the URL is not absolutely necessary so we should decide if the advantages are worth the trouble.

Transport Config

<!--  Directly defined ConnectionFactory  -->
<bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"

<!-- This looks up a jms Destination -->
<jee:jndi-lookup id="service1Queue" jndi-name="jms/Service1Queue">
    <!-- newline-separated, key-value pairs for the environment (standard Properties format) -->
    <!-- It´s probably also possible to share the environment via a refrence -->


<bean id="jmsConf1" class="JMSConfig"
    <!-- alternatively

This is my proposal for a new Config Element of Client and Endpoint named TransportConfig. TransportConfig is a marker interface. The classs JMSConfig implements this interface and contains the special config settings for JMS. Here I only show some few settings. For a complete list we could take a look at the JMSComponent in Camel and see which we need. They also include declarative transactions which we should also try to implement.

I have used the new p Style from spring for the xml sample but it is a normal Bean. The first parameter is a reference to a connection Factory bean. The next two parameters are taken from the Camel JMSComponent as illustration of what we could configure. The last property is for the target JMS Destination. It can be set either as a reference to a bean or as a string. In this case I used the reference to a bean and retrieve the Destination by doing a JNDI lookup. Alternatively I could have set the targetDestination name with a string that defines a queue in the chosen JMS provider.

If you don´t want to use the above described override by using the URL parameters you can also use Springs templating mechanism to support basic configs that are then overriden in some properties. Here is a short sample:

<bean id="jmsConf1" class="JMSConfig"
    <!-- alternatively

<bean id="jmsConf2" class="JMSConfig" parent="jmsConf1"

Here the jmsConf2 will have all properties from jmsConf1 and then override some.


I think this new configuration style could be easily built into CXF and would improve the experience for users dramatically. What do you think about it? Are there other ideas how to do a better config for CXF?


  1. Anonymous

    Looks good.

    Do you have any idea when this proposal going to be implemented in CXF?



    1. I am currently working on it myself. On the trunk I have already introduced the new config behind the scenes. The JMSConduit and JMSDestination already use a JMSConfiguration objects internally. Currently this is built from the old configs but in a later step it will be possible to define it like proposed in the article. At the moment I do not yet know what is the best way to transport the config information from the client definition to the JMSConduit. As a change in the client and endpoint configs is a CXF global thing I will also try to reach a consensus among the CXF developers before implementing it.

      1. Anonymous

        Thanks Christan.

         I wrote a sample service with java first approach using jms transport. How can I look at the wsdl in this scenario as it is going to be generated automatically.

        I tried using WSDLNamespace specified in the jms-conduit with no luck.

        Any pointers?

        -- Krishna

        1. There is no standard way to return a wsdl with jms. So currently you can not see the generated wsdl. An easy way to get the wsdl is to also publish an http endpoint for this purpose. Generally I would not advise to start from java and generate the WSDL on the fly. If you want to start from java then it is better to use java to generate the WSDL and then use this WSDL for code generation in client and server.

          There is only one case where I would advise to do simple java first. If you have an application consiting of client and server and they communicate through soap then it can be a good idea to use java first. The reason is that you have both ends under direct control and both ends are in the same release schedule. In any case where you offer your service to the outside world go the extra step and first generate the WSDL. 

          1. Anonymous

            Thanks for the reply.

            I was trying to layer in the security with JMS transport and CXF. Can you suggest the best practice?

            I am thinking of writing the interceptors at both server and client end which can add headers to JMS message and retrieve the same respectively.

            Does webservices secure extension work for JMS transport as well ?


            1. What do you mean by layering security in? Can you elaborate your security requirements?

              In jms you have basic security via username / password and access control for queues. Additionally you can use ssl to communicate to the jms server.

               I think you can use ws security with jms. It should be the same configuration as with http.