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:[EMAIL PROTECTED]
> Sent: 02 February 2007 16:26
> To: [email protected]
> 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:[EMAIL PROTECTED]
> Sent: 02 February 2007 10:27
> To: [email protected]
> 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:[EMAIL PROTECTED]
> > Sent: 01 February 2007 20:22
> > To: [email protected]
> > 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
> >
> >
>
