Using the Spring JmsTemplate and Messagelistener really improved the
jms transport code. I was able to remove much infrastructure code where
we simply reinvented the wheel. So I think it was a good idea to use it
versus doing it all from scratch.
There is one problem with these spring classes
Just a little history on this...
Originally, the JMS transport only used the JMS API's directly. I think the
version on the 2.0 branch still is that way. You may want to look at that as
a starting point if you need a custom version.
Around Aug/Sept 2008, Christian did a lot of work to refa
her than having each project invent and maintain its own--and
for everyone happy that we've moved from org.springframework.* to org.cxf.*,
several more would be concerned about our move to a lesser-used and -tested
internal framework.
Glen
--
View this message in context:
http://cxf.547215.n5
and copy it in your code
(keeping the copyright header, of course) and you're done. Apache Banana
would serve as a one-stop formalization of that effort that all developers
can quickly use.
Glen
--
View this message in context:
http://cxf.547215.n5.nabble.com/JMS-transport-strongly-depends-on
CXF JMS transport is powerful and it is good. But the fact simple WSDL-first
deployments depending on JMS strictly require Spring is a bit unexpected...
Glen - my apologies for over-reacting (as usual :-))
Sergey
>
>
>> --
>>
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/JMS-transport-strongly-depends-on-Spring-tp2262704p2264402.html
>> Sent from the cxf-dev mailing list archive at Nabble.com.
>>
>
>
ome users of CXF just do not want to use Spring ?
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/JMS-transport-strongly-depends-on-Spring-tp2262704p2264402.html
> Sent from the cxf-dev mailing list archive at Nabble.com.
>
27;s JARs
> instead. Such a wrapping would allow us to use Spring to our heart's
> content while at the same time truthfully saying we're 100% Spring-free.
> (Or would we then need to worry about supporting non-Banana deployments?
> :)
>
> --
> View this message in co
Or would we then need to worry about supporting non-Banana deployments? :)
--
View this message in context:
http://cxf.547215.n5.nabble.com/JMS-transport-strongly-depends-on-Spring-tp2262704p2264402.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Hi Christian
Indeed, I can see JMSDestination & JMSFactory importing a lot of Spring
classes, so my last commit was futile, I started working yesterday on the
test which I did not finish, but that work will need to be parked for now...
In fact, I was definitely blind yesterday, removed Initializi
Hi Sergey,
this does not really work as JmsTemplate and also MessageListener are
used independently of the way you configure the jms endpoint.
Sadly spring does not offer JmsTemplate and MessageListener in a
packaging that is independent of the rest of spring. Still these classes
really simpl
Hi Willem
On Tue, Aug 3, 2010 at 11:15 AM, Willem Jiang wrote:
> Hi Sergey,
>
> CXF JMS transport is base on Spring JMS template now, so even you remove
> the spring dependency of JMSConfiguration. You can't let the
> cxf-jms-transport work without Spring :(.
>
> What's your plan about it ?
>
> M
Hi Sergey,
CXF JMS transport is base on Spring JMS template now, so even you remove
the spring dependency of JMSConfiguration. You can't let the
cxf-jms-transport work without Spring :(.
What's your plan about it ?
Willem
Sergey Beryozkin wrote:
Hi
I'm looking at the issue to do with the
Hi
I'm looking at the issue to do with the JMS transport strongly depending on
Spring.
As it happens, JMSConfiguration implements (Spring) InitializingBean for the
only purpose of verifying that
a connectionFactory has been set.
This causes problems when doing non-Spring CXF deployments.
Generall
13 matches
Mail list logo
