cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Soltysik, Seumas" <Seumas.Solty...@iona.com>
Subject RE: fix for CXF-393
Date Mon, 05 Feb 2007 16:14:36 GMT
+1

-----Original Message-----
From: Tully, Gary [mailto:Gary.Tully@iona.com]
Sent: Monday, February 05, 2007 11:02 AM
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