Hi Gray,
I think you can begin to do the
JMSConstants.JMS_SERVER_REQUEST|RESPONSE_HEADER patch. It only effect
to JMS transport.
Current CXF puts all the Context in Message and we also provides JAXWS
context API can mapping the Message holding context to JAXWS front end.
I think your means gate is same with my mapping . You can find the
code by seach this class ContextPropertiesMapping.
We can make the gate thing more powful.
Cheers,
Willem
Tully, Gary wrote:
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
