cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Proposal for a new JMS configuration for CXF
Date Mon, 01 Sep 2008 07:03:05 GMT
Hi Glen,

thanks for the link to the spec. That´s astonishing they use quite the 
same URL format (IRI) I imagined. I had not read the spec before. 
Perhaps they were inspired by camel too ;-) But they strictly map the 
IRI to message headers and properties. So we probably should set our own 
parameters separately from the URL.

The spec mostly talks about the configuration by WSDL. I think we should 
separate WSDL config from Spring config. The WSDL config typically is 
defined by standards authorities so I think
we would give away flexibility if we take this format also for our own 
internal config. Instead I would map the WSDL config to our internal config.

On the other hand we should make sure to implement all options that the 
Soap Jms spec defines. So implementing the spec will be quite easy.

Best regards


Glen Mazza schrieb:
> Christian, I would take a look at the IBM document attached here:  
> and the specification it links to:
> I'm unsure of the relation to these documents to what you're proposing, nor
> am I necessarily recommending we do what they do, but I'm mentioning this in
> case there is something important in these documents that you might have
> overlooked in your suggestions.
> Glen
> Christian Schneider wrote:
>> Hi,
>> after Glen´s Mail about my tutorial for setting up JMS for CXF with 
>> Apache Camel on the dev list there was a discussion about improvements 
>> for the JMS config for CXF.
>> I have written a proposal how I think this could be done. My focus is 
>> only on the configuration syntax not the implementation but I think it 
>> can be done.
>> Here is the link to the proposal. I would be very interested in your 
>> opinions about this style of configuration:
>> Best regards
>> Christian
>> -- 
>> Christian Schneider
>> ---


Christian Schneider

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message