[HEADS UP] - BlueprintCamelContext startup behavior change coming in 2.19

[Quinn Stevenson <qu...@pronoia-solutions.com>]

A PR ( https://github.com/apache/camel/pull/1297 <https://github.com/apache/camel/pull/1297> ) has been merged into the master branch to make the startup behavior of the BlueprintCamelContext a little more consistent with OSGi Blueprint ( https://issues.apache.org/jira/browse/CAMEL-10513 ).

There is a possibility of some backward compatibility issues with this change if other Blueprint beans depend on the state of the BlueprintCamelContext in their "init-method".  Before this PR, the BlueprintCamelContext may or may not have been started when the "init-methods" for other beans were called, but in most cases, the context had been started before the other “init-methods” were called.  After this PR, the BlueprintCamelContext will not be started until the BlueprintContainer has been fully created.  Therefore, the context will not have been started (at least by OSGi/Blueprint) when “init-methods” are called.

The camel-example-mybatis project illustrates this backward compatibility issue, and was changed in this PR to removed the dependency on the state of the context in the init-method of a bean.

Re: [HEADS UP] - BlueprintCamelContext startup behavior change coming in 2.19

[Grzegorz Grzybek <gr...@gmail.com>]

Hello

I run all camel-test-blueprint tests. Some time ago I added multiple
synchronization points to
org.apache.camel.test.blueprint.CamelBlueprintTestSupport and all these
sync points also rely on BlueprintEvent.CREATED event (and sometimes even
on BlueprintEvent.FAILURE for fail scenarios).

But because camel-test-blueprint tests also wait for CamelContext OSGi
service, the change doesn't affect such tests.

thanks
Grzegorz Grzybek

2016-12-05 15:44 GMT+01:00 Quinn Stevenson <qu...@pronoia-solutions.com>:

> A PR ( https://github.com/apache/camel/pull/1297 <
> https://github.com/apache/camel/pull/1297> ) has been merged into the
> master branch to make the startup behavior of the BlueprintCamelContext a
> little more consistent with OSGi Blueprint ( https://issues.apache.org/
> jira/browse/CAMEL-10513 ).
>
> There is a possibility of some backward compatibility issues with this
> change if other Blueprint beans depend on the state of the
> BlueprintCamelContext in their "init-method".  Before this PR, the
> BlueprintCamelContext may or may not have been started when the
> "init-methods" for other beans were called, but in most cases, the context
> had been started before the other “init-methods” were called.  After this
> PR, the BlueprintCamelContext will not be started until the
> BlueprintContainer has been fully created.  Therefore, the context will not
> have been started (at least by OSGi/Blueprint) when “init-methods” are
> called.
>
> The camel-example-mybatis project illustrates this backward compatibility
> issue, and was changed in this PR to removed the dependency on the state of
> the context in the init-method of a bean.
>
>
>