Deploy feature into fabric: feature's start-level attribute is ignored

[alstsever_alain.saint-sever]

Hi,

Maybe a bug:

I have set the start-level attribute in my feature to '80' and every time I deploy it into a fabric container all my bundles have a start-level value of '60'.

If I deploy the same feature into a non fabric ESB then my bundles have the right start-level value of '80'.

Another point: it appears that bundles, when deployed into a fabric container, are installed in any order. I have some bundles that make use of camel and camel-cxf endpoints and each time I have errors because the camel-cxf feature is installed after my bundles (error is "org.apache.camel.ResolveEndpointFailedException: ... due to: No component found with scheme: cxf"). I must perform a remote SSH login on the fabric container and manualy refresh my failed bundles to fix the issue.

How can I get the same behavior as in a non fabric deployment where features are installed in the expected/defined order?

Thank you.

[alstsever_alain.saint-sever]

Hum auto reply:

the feature I deploy via the FMC to a remote fabric container does not appear with the features:list command (nor my repository with the features:listurl command).

I suspect this is due to my feature being installed by the maven proxy, as a result my bundles are found and deployed (my bundles and the feature are copied to the data/maven/agent folder of the container) but the feature is not visible by the container itself. Strange.

Is this the expected behavior?

[iocanel]

Any feature repository (and all its features) that is assigned to any profile in fabric should be listed using features:listurl (and features:list). So this sounds like a bug.

Now regarding the start-level thing. The order that the bundles are started by the fabric agent is determined by the resolver.

If the bundle requirements and capabilities are properly expressed in the bundle headers, the resolver will determine the correct startup order and you shouldn't have issues. So my guess is that the dependency on cxf is poorly expressed or not expressed at all.

[alstsever_alain.saint-sever]

Hi,

As for "the dependency on cxf is poorly expressed or not expressed at all", here is an extract of one of my bundle header:

Import-Package =

        META-INF.cxf;version="[2.6,3)",

        org.apache.camel;version="[2.10,2.11)",

        org.apache.camel.builder;version="[2.10,2.11)",

        org.apache.camel.component.cxf;version="[2.10,2.11)",

        org.apache.camel.component.cxf.common.message;version="[2.10,2.11)",

        org.apache.camel.component.cxf.converter;version="[2.10,2.11)",

        org.apache.camel.component.jms;version="[2.10,2.11)",

        org.apache.camel.osgi;version="[2.10,2.11)",

        org.apache.camel.processor;version="[2.10,2.11)",

        org.apache.camel.spi;version="[2.10,2.11)",

        org.apache.camel.util;version="[2.10,2.11)",

        org.apache.cxf;version="[2.6,2.7)",

        org.apache.cxf.binding;version="[2.6,2.7)",

        org.apache.cxf.binding.soap;version="[2.6,2.7)",

        org.apache.cxf.binding.soap.spring;version="[2.6,2.7)",

        org.apache.cxf.bus;version="[2.6,2.7)",

        org.apache.cxf.bus.resource;version="[2.6,2.7)",

        org.apache.cxf.bus.spring;version="[2.6,2.7)",

        org.apache.cxf.buslifecycle;version="[2.6,2.7)",

        org.apache.cxf.catalog;version="[2.6,2.7)",

        org.apache.cxf.configuration;version="[2.6,2.7)",

        org.apache.cxf.configuration.spring;version="[2.6,2.7)",

        org.apache.cxf.endpoint;version="[2.6,2.7)",

        org.apache.cxf.headers;version="[2.6,2.7)",

        org.apache.cxf.message;version="[2.6,3)",

        org.apache.cxf.phase;version="[2.6,2.7)",

        org.apache.cxf.resource;version="[2.6,2.7)",

        org.apache.cxf.transport;version="[2.6,2.7)",

        org.apache.cxf.transport.http;version="[2.6,2.7)",

        org.apache.cxf.transport.http.policy;version="[2.6,2.7)",

        org.apache.cxf.transport.http_jetty;version="[2.6,2.7)",

        org.apache.cxf.transports.http;version="[2.6,2.7)",

        org.apache.cxf.workqueue;version="[2.6,2.7)",

        org.apache.cxf.wsdl;version="[2.6,2.7)",

        org.apache.cxf.wsdl11;version="[2.6,2.7)"

So you can see that both CXF and camel cxf imports are expressed. However, the resolver installs both CXF and camel cxf after my bundle.

Did I miss something (Require-Bundle for e.g.)? I remember that we had to add a "<Require-Bundle>org.apache.cxf.bundle</Require-Bundle>" in the Maven Bundle Plugin section but now that the big CXF bundle is gone do we still have such a requirement?

Thank you.

[iocanel]

Hmmm, I guess I was wrong about my assumption.

I'll try to reproduce that myself and get back to you.

[alstsever_alain.saint-sever]

Hi,

Is there somewhere a working Fabric camel-cxf sample? Do we still have to set the Require-Bundle MANIFEST header to some value?

Thanks.

[ffang]

Hi,

No, you needn't use <Require-Bundle>org.apache.cxf.bundle</Require-Bundle> any more provided you already import all necessary cxf package.

Freeman

[alstsever_alain.saint-sever]

Ok. Thank you for answering this point. Then my issue still exists: my bundle is deployed by fabric before camel-cxf in spite of the camel+cxf imports.

Ioannis: did you have some time to try to reproduce the issue?

Thanks.

[iocanel]

I didn't had the time to run the exact scenario, but run a couple of others that I had handy with no issues.

I'll try to run a camel-cxf example against fabric as soon as possible.

[iocanel]

My previous statement that the bundle startup will be ordered based on their requirements/capabilities was incorrect. Requirements / Capabilities only affect the resolution but is no related to the startup order of your bundles.

What you could do, is to add a reference to the component resolver of the cxf component, which will make your camel context to wait till the cxf becomes available.

In blueprint it would be like this.

Note however, that you don't want this to also be expressed in the headers of the bundles, as the camel bundles currently do not define their exported services, which will cause resolution to fail.

If this is the case, then you could also add the following header in your bundle:

Import-Service: org.apache.camel.spi.ComponentResolver;availability:=optional;filter="(component=cxf)

[alstsever_alain.saint-sever]

Thank you Ioannis. Regarding your remark: if requirements / capabilities doesn't drive startup order then how does the Fabric agent proceed to know the order?

I'll add the Import-Service into the header and give it a try. I think such "tips" should be documented since this will become a common "issue" when deploying bundles using camel-cxf into Fabric containers.

Regards,

[iocanel]

Fabric will install the bundles, resolve them and then start them in the same order they were received from the obr resolver.

In your case, the packages that your bundle needs are available at the time of startup (camel-cxf bundle is installed and resolved), but the services required in order the camel component to be properly resolved are not available. This is why I proposed you to use a service reference that will delay the startup of your context till the actual component resolver is available.

[alstsever_alain.saint-sever]

Hi Ioannis,

Just to let you know that adding a reference to Camel ComponentResolver does not resolve the issue in a Fabric environment. I still get exception "org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: cxf://bean:xxx?dataFormat=POJO due to: No component found with scheme: cxf".

With my bundle-context-osgi.xml file containing:

<osgi:reference id="camelSpiCXF" interface="org.apache.camel.spi.ComponentResolver" filter="(component=cxf)" />

I can see in the fabric container's log that my bundle correctly waits for the ComponentResolver osgi reference:

- Looking for mandatory OSGi service dependency for bean \[camelSpiCXF\] matching filter (&(objectClass=org.apache.camel.spi.ComponentResolver)(component=cxf))

- Found mandatory OSGi service for bean \[camelSpiCXF\]

However Camel does not seem to know the CXF component at this stage (I got the exception a couple of seconds after these log entries). I have to manually refresh my bundle to make the route starts.

Regards

[iocanel]

You are using the spring dsl right?

[alstsever_alain.saint-sever]

Yes.