Karaf - managing Camel routes startup behavior

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Karaf - managing Camel routes startup behavior

kmoens
Hi there,

we have some bundles with Camel routes defined in META-INF/spring/*.xml file.
When we deploy such a bundle in karaf, these routes are started automatically.

What we want to achieve is to have a kind of condition based behavior that will get 'a go or no go' wether our Camel route should be started or not, depending on an external parameter.

It is not enough to have the 'autostartup' defined in the route or when using features to have the <bundle start='false'> configured, it's more a kind of hook on the deploy process we're looking for I guess.

Unless other briliant ideas are out there somewhere...

Thanks for your reply.

Kris
 

 
 
Reply | Threaded
Open this post in threaded view
|

Re: Karaf - managing Camel routes startup behavior

jbonofre
Hi Kris,

You can define a bean (or a route) which start another route, depending
on condition, properties, etc.

You set the autostartup="false", and start the route by the bean.

This bean could be on another package, and looks for a camel context
(exposed as an OSGi service).

Does it fill your requirements ?

Regards
JB

On 01/18/2012 03:35 PM, kmoens wrote:

> Hi there,
>
> we have some bundles with Camel routes defined in META-INF/spring/*.xml
> file.
> When we deploy such a bundle in karaf, these routes are started
> automatically.
>
> What we want to achieve is to have a kind of condition based behavior that
> will get 'a go or no go' wether our Camel route should be started or not,
> depending on an external parameter.
>
> It is not enough to have the 'autostartup' defined in the route or when
> using features to have the<bundle start='false'>  configured, it's more a
> kind of hook on the deploy process we're looking for I guess.
>
> Unless other briliant ideas are out there somewhere...
>
> Thanks for your reply.
>
> Kris
>
>
>
>
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Karaf-managing-Camel-routes-startup-behavior-tp3669403p3669403.html
> Sent from the Karaf - User mailing list archive at Nabble.com.

--
Jean-Baptiste Onofré
[hidden email]
http://blog.nanthrax.net
Talend - http://www.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf - managing Camel routes startup behavior

kmoens
Hi JB,

thanks for the idea. Not sure this covers our needs, we want to control automatically the startup of deployed routes at both boottime of karaf and deploy time of a new bundle containing routes.

In this case the bean you proposed should be listening on 'deploy events' of bundles having routes in spring xml files, how to achieve that?

When I activate trace, I see the follwing messages logged:

13:41:18,915 | INFO  | SpringOsgiExtenderThread-3 | OsgiBundleXmlApplicationContext | 47 - org.springframework.context - 3.0.5.RELEASE | Refreshing OsgiBundleXmlApplicationContext(bundle=com.my.samples.Sample1, config=osgibundle:/META-INF/spring/*.xml): startup date [Wed Jan 18 13:41:18 CET 2012]; root of context hierarchy
13:41:18,915 | TRACE | SpringOsgiExtenderThread-3 | OsgiBundleResourcePatternResolver | 60 - org.springframework.osgi.io - 1.2.1 | Found root resources for [osgibundle:/META-INF/spring/] :{URL [bundle://138.0:0/META-INF/spring/]}
13:41:18,915 | TRACE | SpringOsgiExtenderThread-3 | OsgiBundleResourcePatternResolver | 60 - org.springframework.osgi.io - 1.2.1 | Resolved location pattern [osgibundle:/META-INF/spring/*.xml] to resources [URL [bundle://138.0:0/META-INF/spring/Sample1.xml]]

I was wondering if we could find a way to extend the spring deploy process some how and add our condition.

BRs,
Kris
Reply | Threaded
Open this post in threaded view
|

Re: Karaf - managing Camel routes startup behavior

Guillaume Nodet
You should listen to CamelContext objects being registered as OSGi services.
If they all have autostart = false, you could then manually control them.

On Mon, Jan 23, 2012 at 10:51, kmoens <[hidden email]> wrote:

> Hi JB,
>
> thanks for the idea. Not sure this covers our needs, we want to control
> automatically the startup of deployed routes at both boottime of karaf and
> deploy time of a new bundle containing routes.
>
> In this case the bean you proposed should be listening on 'deploy events' of
> bundles having routes in spring xml files, how to achieve that?
>
> When I activate trace, I see the follwing messages logged:
>
> 13:41:18,915 | INFO  | SpringOsgiExtenderThread-3 |
> OsgiBundleXmlApplicationContext | 47 - org.springframework.context -
> 3.0.5.RELEASE | Refreshing
> OsgiBundleXmlApplicationContext(bundle=com.my.samples.Sample1,
> config=osgibundle:/META-INF/spring/*.xml): startup date [Wed Jan 18 13:41:18
> CET 2012]; root of context hierarchy
> 13:41:18,915 | TRACE | SpringOsgiExtenderThread-3 |
> OsgiBundleResourcePatternResolver | 60 - org.springframework.osgi.io - 1.2.1
> | Found root resources for [osgibundle:/META-INF/spring/] :{URL
> [bundle://138.0:0/META-INF/spring/]}
> 13:41:18,915 | TRACE | SpringOsgiExtenderThread-3 |
> OsgiBundleResourcePatternResolver | 60 - org.springframework.osgi.io - 1.2.1
> | Resolved location pattern [osgibundle:/META-INF/spring/*.xml] to resources
> [URL [bundle://138.0:0/META-INF/spring/Sample1.xml]]
>
> I was wondering if we could find a way to extend the spring deploy process
> some how and add our condition.
>
> BRs,
> Kris
>
>
> --
> View this message in context: http://karaf.922171.n3.nabble.com/Karaf-managing-Camel-routes-startup-behavior-tp3669403p3681405.html
> Sent from the Karaf - User mailing list archive at Nabble.com.



--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Karaf - managing Camel routes startup behavior

kmoens
Hi Guillaume,

in our environment we do not control the content of the routes deployed, hence we cannot rely on the fact that the autostart has been disabled.

Anothere idea was to look at a spring BeanPostProcessor implementation.

BRs,
Kris