Hi Eoghan, Thanks, yes indeeedy, Gary. -----Original Message----- From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] Sent: 05 February 2007 17:00 To: [email protected] Subject: RE: fix for CXF-393
Hi Gary, Agreed, no point in going over-board on this if no one can even articulate a specific use-case. Presumably you want the patch applied? I've just kicked off a test run on Linux, will commit your patch once this completes. Cheers, Eoghan > -----Original Message----- > From: Tully, Gary [mailto:[EMAIL PROTECTED] > Sent: 05 February 2007 16:02 > To: [email protected] > Subject: RE: fix for CXF-393 > > On thinking more on the use cases, for routing/proxy/intermediary, the > auto property copy would need to be based on the contents of an > ultimate destination reply message rather than on the original request > message. A trivial auto copy from the original request to the ultimate > reply is wrong, it is actually interfering. > > It looks like there is no real use case for auto copy of properties or > echo of properties as it should be called. If such a need arises we > can deal with it by adding a copy filter based on a single regexp or > the more elaborate ant-fileset-like scheme used in the FiltersType > referenced by Eoghan. (btw: while nice, I think the fileset-like > filter is overkill for a simple string name match as property names > are quite > restricted) > > For the moment, we can fix the issue by separating the request and > reply context such that application code needs to explicitly transfer > properties that it is interested in. > In normal and typical operation, request and reply String message > properties are separate entities managed only by the JMS user (CXF) > and JMS implementation. > > > I have uploaded a patch[1] that implements the separation and reflects > the changes in the unit and system tests. > > Thanks, > Gary. > > [1] > https://issues.apache.org/jira/secure/attachment/12350354/cxf- > 393.rel.pa > tch > > -----Original Message----- > From: Glynn, Eoghan [mailto:[EMAIL PROTECTED] > Sent: 02 February 2007 17:09 > To: [email protected] > Subject: RE: fix for CXF-393 > > > 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 > > > > > > > > >
