cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tully, Gary" <Gary.Tu...@iona.com>
Subject RE: fix for CXF-393
Date Mon, 05 Feb 2007 17:08:26 GMT
Hi Eoghan,
Thanks, yes indeeedy,
Gary. 

-----Original Message-----
From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
Sent: 05 February 2007 17:00
To: cxf-dev@incubator.apache.org
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: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