In the end, the solution was to replace
with
This way, the bean is still referencend and can be called while the other
context is shutting down.
- Martin
Martin Lichtin-2 wrote
> This didn't make a difference.
>
> However, something else I noticed. There is a second CamelContext defined
>
This didn't make a difference.
However, something else I noticed. There is a second CamelContext defined in
the same Blueprint file.
This Camel context is shutdown first.
As it contains a from(jms:) endpoint, the shutdown takes a few secs (and that's why the
timer-based route in the "myRouteCon
Try remove the depends-on, not sure if blueprint shutdown in reverse
order and therefore the bean before camel etc.
On Tue, May 26, 2015 at 9:56 PM, Martin Lichtin
wrote:
> Using Blueprint in an OSGi bundle:
>
> class="myPkg.MyBean">
>
>
> http://camel.apache.org/schema/blueprint";
Using Blueprint in an OSGi bundle:
class="myPkg.MyBean">
http://camel.apache.org/schema/blueprint";
xsi:schemaLocation="http://camel.apache.org/schema/blueprint
http://camel.apache.org/schema/blueprint/camel-blueprint.xsd";
id="myRouteContext" depends-on="myBean">
Using Blueprint in an OSGi bundle:
http://camel.apache.org/schema/blueprint";
xsi:schemaLocation="http://camel.apache.org/schema/blueprint
http://camel.apache.org/schema/blueprint/camel-blueprint.xsd";
id="myRouteContext" depends-on="myBean">
Hi
Are you using a spring xml file? Then its spring app context that is
the registry. Camel does not remove any beans from it. Its spring that
does that. So maybe you have some depends-on spring attribute order
wrong or something.
On Tue, May 26, 2015 at 12:41 PM, Martin Lichtin
wrote:
> Is anyo
