cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tully, Gary" <Gary.Tu...@iona.com>
Subject fix for CXF-393
Date Thu, 01 Feb 2007 20:21:49 GMT
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
JMSConstants.JMS_SERVER_REQUEST|RESPONSE_HEADER and ensure 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] https://issues.apache.org/jira/browse/CXF-393
[2]
http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/
org/apache/cxf/systest/jms/JMSClientServerTest.java?view=markup
http://svn.apache.org/viewvc/incubator/cxf/trunk/systests/src/test/java/
org/apache/cxf/systest/jms/GreeterImplTwoWayJMS.java?view=markup


Mime
View raw message