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 Fri, 02 Feb 2007 17:05:38 GMT

Gary,

Just on the detail of what the config should look like ... see the
FiltersType defined in the security.xsd:

    <xs:complexType name="FiltersType">
        <xs:sequence>
            <xs:element name="include" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
            <xs:element name="exclude" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType> 

... which is intended to allow for a set of inclusion and/or exclusion
regular expressions to be configured ... in a different context sure
enough, but might be worth following for consistency.

So if you were to follow this pattern, in your case the relevant config
might look something like:

  <jms:EchoPropertyFilters>
      <jms:include>My.*</jms:include>
      <jms:include>JMS.*</jms:include>
      <jms:exclude>JMS_IBM.*</jms:exclude> 
  </jms:EchoPropertyFilters>

Not sure how much flexibility in terms of wildcarding is supported when
wiring the config up with the programmatic bean ... Andrea would know.

Cheers,
Eoghan

> -----Original Message-----
> From: Tully, Gary [mailto:Gary.Tully@iona.com] 
> Sent: 02 February 2007 16:26
> 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.JMSDestination
> ConfigBean
> ">
>   <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.JMSDestination
> ConfigBean
> ">
>     ...
>   </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