[
https://issues.apache.org/jira/browse/CAMEL-12980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16739379#comment-16739379
]
Grzegorz Grzybek edited comment on CAMEL-12980 at 1/10/19 1:16 PM:
-------------------------------------------------------------------
I understand the problem... CAMEL-10513 was a big change, but actually not
against any specification... It's especially true with context using
{{autoStart="false"}}.
bq. A bundle is in the ACTIVE state when it has been successfully started and
activated.
means exactly this - "activated" == "called BundleActivator.start()" which is
NOT the same as successfully starting Camel Context or *even* creating
Blueprint Container.
But if we look at blueprint specification:
{quote}
*121.3.2.2 Failure*
If at any time there is a failure, the Blueprint Container must:
# State = FAILURE
# Unregister the Blueprint Container service.
# Destroy the Blueprint Container.
# Wait for the Blueprint bundle to be stopped.
{quote}
Which may be a reason to call back from failed Camel context/route to their
blueprint container.
{{org.osgi.service.blueprint.container.BlueprintContainer}} doesn't have any
such callback methods, but
{{org.apache.aries.blueprint.services.ExtendedBlueprintContainer}} may be
called to grab {{org.osgi.service.blueprint.container.BlueprintListener}} to
send Failure event like this:
{code:java}
ExtendedBlueprintContainer.getEventDispatcher().blueprintEvent(new
BlueprintEvent(BlueprintEvent.FAILURE, getBundle(), getExtenderBundle(), new
Throwable("Camel context says: oops"));
{code}
Then Karaf would catch such event using
{{org.apache.karaf.bundle.state.blueprint.internal.BlueprintStateService}} and
alter output of {{bundle:list}}.
I think it's doable.
was (Author: gzres):
I understand the problem... CAMEL-10513 was a big change, but actually not
against any specification... It's especially true with context using
{{autoStart="false"}}.
bq. A bundle is in the ACTIVE state when it has been successfully started and
activated.
means exactly this - "activated" == "called BundleActivator.start()" which is
NOT the same as successfully starting Camel Context or *even* creating
Blueprint Container.
But if we look at blueprint specification:
{quote}
*121.3.2.2 Failure*
If at any time there is a failure, the Blueprint Container must:
# State = FAILURE
# Unregister the Blueprint Container service.
# Destroy the Blueprint Container.
# Wait for the Blueprint bundle to be stopped.
{quote}
Which may be a reason to call back from failed Camel context/route to their
blueprint container.
{{org.osgi.service.blueprint.container.BlueprintContainer}} doesn't have any
such callback methods, but
{{org.apache.aries.blueprint.services.ExtendedBlueprintContainer}} may be
called to grab {{org.osgi.service.blueprint.container.BlueprintListener}} to
send Failure event like this:
{code:java}
ExtendedBlueprintContainer.getEventDispatcher().blueprintEvent(new
BlueprintEvent(BlueprintEvent.FAILURE, getBundle(), getExtenderBundle(), new
Throwable("Camel context says: oops"));
{code}
Then Karaf would catch such event using
{{org.apache.karaf.bundle.state.blueprint.internal.BlueprintStateService}} and
alter output of {{bundle:list}}.
I think it's doable.
> Bundle in 'Active' State but Camel Context not initialized
> ----------------------------------------------------------
>
> Key: CAMEL-12980
> URL: https://issues.apache.org/jira/browse/CAMEL-12980
> Project: Camel
> Issue Type: Bug
> Components: camel-blueprint
> Affects Versions: 2.20.1, 2.21.1
> Reporter: Xilai Dai
> Assignee: Grzegorz Grzybek
> Priority: Major
> Fix For: 3.0.0, 2.24.0
>
> Attachments: blueprint.xml
>
>
> The camel context can't get initialized when validation of the
> RouteDefinition failed (e.g. typo in Uri or add an unsupported option in
> Uri), but when deploy the blueprint, the CamelContext startup and then
> shutdown, but the bundle status is still 'Active', only a
> FailedToCreateRouteException ERROR is logged.
> 318 │ Active │ 80 │ 0.0.0 │ blueprint.xml
> Attached the simple blueprint.xml for reproduce it.
> The expected behaviour is the bundle is in the 'Failure' status in this case.
> The fix proposal from my side is, move the call of "this.maybeStart()" from
> blueprintEvent() method to the constructor of the BlueprintCamelContext
> class. then this kind of Route definition error can be processed during the
> Blueprint "CREATING" phase. Currently, the start() is invoked after Blueprint
> in "CREATED" phase. (I tested this fix locally and have the expected
> 'Failure' bundle status)
> (This issue is found in Camel 2.20.x, 2.21.x, but it may affects also on
> master branch)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
