Hi Gary, You wrote, "However, the lack of separation between request and reply is plain wrong............By default no properties would[should] be copied."
I could't agree more. As for the rest of your proposal, I think it is reasonable. However, I can't help wondering if we are trying to solve an issue that does not exist. We started with the assumption that because in the "original" code, properties were being copied from request message to response, that there must have been a rationale for doing this. I have yet to hear this rationale expressed. I have not seen a use case/integration pattern which justifies this approach. Therefore I think we are reacting to an incorrect original assumption. Until we see evidence that properties of request messages should be copied to properties of reply message, I believe the solution is to not provide any capabilites to copy from request to reply. Regards, Seumas -----Original Message----- From: Tully, Gary [mailto:[EMAIL PROTECTED] Sent: Friday, February 02, 2007 11:26 AM To: [email protected] Subject: RE: fix for CXF-393 Hi Eoghan et all, I do agree that having to explicitly copy properties will be bad for proxy of intermediaries. However, the lack of separation between request and reply is plain wrong. The request context should be read-only w.r.t JMS properties. I think the best solution included the separation, REQUEST_HEADERS and RESPONSE_HEADERS with the option through config to propagate a set of string properties from request context to reply context automatically. By default no properties would be copied. The configured auto-copying would occur from the request context before dispatch, during dispatch both the request and response contexts would be available to the application. Only string properties from the response context will be set on the reply. To enable this, some config in the destination is needed. A string regular expression, if configured will be used to match properties in the JMS request message and copy them to the response context. Some thing like: <bean id="{http://cxf.apache.org/hello_world_jms}HelloWorldPort.jms-destinatio n" class="org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean "> <property name="serverConfig"> <value> <jms-conf:serverConfig autoCopyMessagePropertyRegExp = "^My*" /> </value> </property> </bean> Would ensure that a JMSMessage property called "MySpecialProp" would automatically be part of a JMS response message. Is the property name to verbose? One other thing, is it possible to wildcard the bean id so that it can apply to all destinations? Some thing like: <bean id="{http://cxf.apache.org/hello_world_jms}*.jms-destination"; class="org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean "> ... </bean> Thanks, Gary. -----Original Message----- From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] Sent: 02 February 2007 10:27 To: [email protected] Subject: RE: fix for CXF-393 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 JMSConstants.JMS_SERVER_RESPONSE_HEADERS). 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. Cheers, Eoghan > -----Original Message----- > From: Tully, Gary [mailto:[EMAIL PROTECTED] > Sent: 01 February 2007 20:22 > To: [email protected] > 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 > 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 > >
