cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <eoghan.gl...@iona.com>
Subject RE: fix for CXF-393
Date Mon, 05 Feb 2007 16:59:47 GMT

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:Gary.Tully@iona.com] 
> Sent: 05 February 2007 16:02
> To: cxf-dev@incubator.apache.org
> 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:eoghan.glynn@iona.com]
> Sent: 02 February 2007 17:09
> To: cxf-dev@incubator.apache.org
> 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:Seumas.Soltysik@iona.com]
> > Sent: 02 February 2007 16:18
> > To: cxf-dev@incubator.apache.org
> > 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:eoghan.glynn@iona.com]
> > Sent: Friday, February 02, 2007 5:27 AM
> > To: cxf-dev@incubator.apache.org
> > 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:Gary.Tully@iona.com]
> > > Sent: 01 February 2007 20:22
> > > To: cxf-dev@incubator.apache.org
> > > 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
> > > 
> > > 
> > 
> 

Mime
View raw message