The only concrete use-case I've heard of motivating bulk copying of headers is a router-type scenario.
Agreed that the default should be to copy nothing. The simplest filtering rule would be to only copy properties that match at least one <include> regexp and don't match any <exclude> regexp. /Eoghan > -----Original Message----- > From: Soltysik, Seumas [mailto:[EMAIL PROTECTED] > Sent: 02 February 2007 16:18 > To: [email protected] > Subject: RE: fix for CXF-393 > > I think we need to answer the basic question: Is it an > accepted pattern for servers to return the same > property/header information sent by client? > In JMS land, aside from the correlationID, I think the answer > to this is no. Keep in mind that message exchanges will not > always occur between CXF clients and servers. For instance if > a CXF client expects a CXF server to return all properties > that it sent to the server, what happens when the client > interacts with a "pure" JMS system that does not implement > the same semantics? > I am not strictly speaking against the filtering, however, I > think that by default properties part of the incoming message > should not be copied into the outgoing message. > Regards, > Seumas > > -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: Friday, February 02, 2007 5:27 AM > 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 > > > > >
