Hi Traccy,
thanks for the link. The article is quite interesting. In practice we
did not encounter any problems till now but we did not mix several
versions of the same bundle so this could still hit us later.
As far as I understand you should be able to use Aries with camel even
though we use spring jms stuff. You simply would not start the spring
osgi extender in that case.
Thanks
Christian
Am 13.10.2010 19:52, schrieb Tracy Snell:
There are some caveats when using Spring-DM and OSGI. Guillaume Nodet does a
far better job than I ever could explaining some of the issues in his blog:
http://gnodet.blogspot.com/2010/03/spring-dm-aries-blueprint-and-custom.html
Regards,
Tracy Snell
On Oct 12, 2010, at 3:08 AM, Christian Schneider wrote:
Hi Madhav,
while it is a shame that you can´t use JmsTemplate and JmsMessagListener
without adding half of the spring jars to your project it does not force you to
use spring for dependency injection.
So you are not very much tied to spring.
Btw. I am using spring on osgi and it works like a charm. The trick is to use
the spring osgi extender to start your contexts and not do it by hand. The
extender will care about the namespace handlers.
So I would say that spring is quite mature on osgi.
Best regards
Christian
Am 11.10.2010 17:54, schrieb Madhav Bhargava:
Hi,
Camel JMS component is tightly coupled with Spring JmsTemplate, which is
rather bad news. Given that Spring with its classloader hack tries to
resolve the namspace handler and fails miserably. It is just not meant for
OSGi setup.
Even if we try to move to Apache Aries Blueprint we still cannot move away
from Spring because of the decisions being taken to tightly couple Spring
framework.
Spring is not a mature framework for OSGi but its good for other
applications. Is there any effort to de-couple Camel API's from Spring
dependencies?
Best Regards,
Madhav
--
----
http://www.liquid-reality.de
--
----
http://www.liquid-reality.de
