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 Fri, 02 Feb 2007 16:38:49 GMT
Hi Gary,
You wrote, 
"However, the lack of separation between request
and reply is plain wrong............By default no properties would[should] be copied."

I could't agree more.

As for the rest of your proposal, I think it is reasonable.
However, I can't help wondering if we are trying to solve an issue that does not exist. We
started with the assumption that because in the "original" code, properties were being copied
from request message to response, that there must have been a rationale for doing this. I
have yet to hear this rationale expressed. I have not seen a use case/integration pattern
which justifies this approach. Therefore I think we are reacting to an incorrect original
assumption. Until we see evidence that properties of request messages should be copied to
properties of reply message, I believe the solution is to not provide any capabilites to copy
from request to reply.
Regards,
Seumas

-----Original Message-----
From: Tully, Gary [mailto:Gary.Tully@iona.com]
Sent: Friday, February 02, 2007 11:26 AM
To: cxf-dev@incubator.apache.org
Subject: RE: fix for CXF-393


Hi Eoghan et all,

I do agree that having to explicitly copy properties will be bad for
proxy of intermediaries. However, the lack of separation between request
and reply is plain wrong. The request context should be read-only w.r.t
JMS properties.

I think the best solution included the separation, REQUEST_HEADERS and
RESPONSE_HEADERS with the option through config to propagate a set of
string properties from request context to reply context automatically.
By default no properties would be copied.
The configured auto-copying would occur from the request context before
dispatch, during dispatch both the request and response contexts would
be available to the application. Only string properties from the
response context will be set on the reply.

To enable this, some config in the destination is needed. A string
regular expression, if configured will be used to match properties in
the JMS request message and copy them to the response context.

Some thing like:
 <bean
id="{http://cxf.apache.org/hello_world_jms}HelloWorldPort.jms-destinatio
n"
 
class="org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean
">
  <property name="serverConfig">
      <value>
         <jms-conf:serverConfig autoCopyMessagePropertyRegExp = "^My*"
/>
      </value>
  </property>
 </bean>

Would ensure that a JMSMessage property called "MySpecialProp" would
automatically be part of a JMS response message.

Is the property name to verbose?

One other thing, is it possible to wildcard the bean id so that it can
apply to all destinations?

Some thing like:
  <bean id="{http://cxf.apache.org/hello_world_jms}*.jms-destination"
 
class="org.apache.cxf.transport.jms.destination.JMSDestinationConfigBean
">
    ...
  </bean>

Thanks,
Gary.

-----Original Message-----
From: Glynn, Eoghan [mailto:eoghan.glynn@iona.com] 
Sent: 02 February 2007 10:27
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