cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: fix for CXF-393
Date Fri, 02 Feb 2007 10:26:31 GMT

Agreed the header copying is over-eager.

However, forcing the application to do this explicitly &
programmatically may not be the best approach.

Suppose I have a bunch of services that may be deployed over JMS, or may
be deployed over some other transport, depending. Now when I'm using
JMS, say I need to always echo an incoming property X back in the
response. If I understood correctly, I'd have to write some code to
retrieve the JMSConstants.JMS_SERVER_REQUEST_HEADERS from the incoming
message, cast to JMSMessageHeadersType, walk the properties list to find
property X value and then copy this into the outgoing
JMSMessageHeadersType instance (keyed on

The problem is that I'd have to remember to do this step for all my
services, but this code would then be extraneous if the services were
re-deployed over some other transport. Fair enough I could factor it out
into a CXF Interceptor or JAX-WS Handler to avoid impacting the servant
code, but then I'd have to remember to install this interceptor when JMS
is in use, and again its extraneous when another transport takes over.

So it seems your other idea to drive this declaratively from the JMS
destination config instead is much cleaner  ... i.e. the user configures
the property set he want to copy over (via say a list of regexps as you
suggest), and the application code remains untouched. If another
transport takes over, the JMS destination config would presumably be
switched out anyway.


> -----Original Message-----
> From: Tully, Gary [] 
> Sent: 01 February 2007 20:22
> To:
> Subject: fix for CXF-393
> Hi,
> I want to nail this issue[1], and I think the root of the 
> problem is that CXF is too eager in it's copying of JMS 
> message properties in the request/reply paradigm.
> Essentially, CXF returns (in a reply message) the JMS message 
> properties that it receives.
> I think the fix is not to copy custom or application level 
> message properties from request messages to reply messages 
> and only deal with the properties that are exposed via the 
> JMS assessors on jms.Message, things like correlationId and 
> replyTo as CXF currently does.
> This means that proxy/intermediary and server applications 
> will have to deal with message properties such that a client 
> will get back what it sent which is a change from the current 
> behavior.
> There is a jms client server system test[2] 
> testContextPropagation which will break unless the server is 
> updated to propagate the context property in the reply. 
> <code>
>   assertTrue("response Headers must conain the app specific 
> property set by request context.", 
>                            responseHdr.getProperty() != null); </code>
> Is the system test broken now?
> Do you think the current behavior is wrong?
> The JMS spec does not state what is correct, only that some 
> properties are readOnly in a request (which we don't violate 
> but don't enforce) and some like those beginning with JMSX 
> are reserved. If properties had to be preserved I guess the 
> spec would state it.
> The alternative is to leave the current behavior and 'gate' 
> the setting of message properties with a regexp such that the 
> set of messages properties that are set on replies can be configured.
> For a JMS implementation that does not allow the setting of 
> properties beginning with JMSX we could default the value of 
> our 'gate' regexp to ^JMSX*.
> Feedback welcome. I am working on a patch that will introduce 
> that properties will have to be explicitly copied from 
> request to reply but I am happy with the 'gate' approach also 
> because proxy or intermediary services may have to respect 
> arbitrary properties in a message.
> Thanks,
> Gary.
> [1]
> [2]
> test/java/
> org/apache/cxf/systest/jms/
> test/java/
> org/apache/cxf/systest/jms/

View raw message