Hi Freeman,
I was looking at code and here are two main problems that we will need
to tackle.
1. By default, we create separate TemporaryQueue for repsonse so we will
need receiver per tempqueue waiting on reply. (so that many threds.)
2. to propogate the JMS response headers back we use JAXW
Hi Ulhas,
Thanks.
How about we introduce Spring JmsTemplate to cxf jms transport, is it
helpful? I'm not familar with spring JmsTemplate but I wanna get more
ideas about it .
Thanks again
Freeman
Ulhas Bhole wrote:
Hi Freeman,
I was looking at code and here are two main problems that we
Hi Freeman,
As per 2.2 roadmap ideas we want to change/rewrite CXF JMS transport to
support SPEC/JMS and use spring JMSTemplates but I guess we need to do
it in such a way that we can keep the current one if someone already
using it atleast for some time.
I didn't got a chance to look at how
Hi Freeman,
FYI, you might take a look at
http://svn.apache.org/viewvc/servicemix/components/bindings/servicemix-jms/trunk/src/main/java/org/apache/servicemix/jms/endpoints/JmsConsumerEndpoint.java?view=markup
and AbstractConsumerEndpoint.java for a sample usage of the Spring JMS
MessageListenerC
Another possibility would be to use an MTOM policy expression [1], oth the
older version used by CXF tests, and use the scheme
extension mechanism to add an additional cxf-specific configuration :
For ex :
http://www.w3.org/2007/08/soap12-mtom-policy";>
This policy expression can be lo
As I mentioned on the ServiceMix dev list, there is a "deficiency" in
the "Client" API that would make this change relatively moot unless the
client API is completely updated. Right now, async invokations are only
available to the jax-ws frontend, and that's really just "faked" via doing a
s
Definitely the "right" way to go, but that requires quite a bit more work to
get there. Hopefully for 2.2 we'll have much of this working. Part of the
issues will be:
1) Getting the policy framework to support all the policy variants
(1.2/1.5/etc...) without configuration
2) Turning on poli
This type of thing is EXTREMELY hard to support. In SOME cases, the users
would have to provide extra metadata into the RSFB/configurations as the
parameterized types wouldn't be available. In other cases, we could deduce
it. In both cases, however, we have to track a lot of extra detail
Just FYI, it is very easy to use camel-jms component (which uses the
Spring JMS template) as a new JMS transport in CXF.
Also here a blog[1] which discusses about it.
[1]
http://www.liquid-reality.de:8080/display/liquid/2008/08/25/Better+JMS+Transport+for+CXF+Webservice+using+Apache+Camel
W
