[iocanel]

Could you please share the log file?

[alstsever_alain.saint-sever]

Hi Ioannis,

Sorry for the delay: I was out of the office today. You'll find my log in attachment.

Regards,

[iocanel]

No worries.

I had a look in your logs and I noticed that your endpoint is using cxf:bean.

In this case you will need to add an osgi reference for the component resolver using (component=cxfbean).

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

I hope this solves the problem.

[alstsever_alain.saint-sever]

Hi Ioannis,

Strange since on the Apache Camel website:

- the 'cxf' component URI format is "cxf:bean:cxfEndpoint\[?options\]" or "cxf://someAddress\[?options\]"

- the 'cxf bean' component URI format is "cxfbean:serviceBeanRef"

So if I judge by the website I am using the 'cxf' camel component.

Anyway I will try tomorrow with the "(component=cxfbean)" filter and let you know the result.

Thanks.

[alstsever_alain.saint-sever]

Hi Ioannis,

No luck: still the same issue with (component=cxfbean) filter.

- org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: cxf://bean:integrationSystem_ApplicationMgmtEndpoint?dataFormat=POJO due to: No component found with scheme: cxf

Note that Camel complains about component named 'cxf' (not 'cxfbean') so, as I supposed in my previous post, I am using the cxf camel component but neither (component=cxf) nor (component=cxfbean) solve this issue.

I would welcome any working camel-cxf sample in Fabric. As of today I fear this cannot work without a manual refresh of the bundles (hardly a solution in a production environment).

I see two solutions:

1) Camel starts the routes after its components are truly available (here it appears that in spite of the osgi reference on org.apache.camel.spi.ComponentResolver, Camel still does not 'see' the component)

or

2) Start all camel bundles before our own bundles using different start levels. This is how it works with a standalone ESB (camel bundles are all started well before ours because of their start levels) but it does not apply in a Fabric container.

Regards,

[iocanel]

For a long term solution, we have changed the startup order so that its based on the requirements and capabilities as I described in my first post. Hopefully, this will be available in the next release. This is somehow close to the what you describe in solution 1.

Solution 2, doesn't deal with the actual problem but its more like a workaround that works well in some cases on standalone. So I am a bit reluctant about it, as I fear that it can cause more issues than it will actually solve.

I'll try to work on adding an example for fabric for camel-cxf, as it seems really strange that the recommended solution fails for this case.

Thanks for the feedback!

[alstsever_alain.saint-sever]

Ioannis,

I had also tried adding a "depends-on" attribute in my camelcontext tag as follows:

but it does not help.

I am using Spring-DM. Is it possible that my issue may be related to the Spring-DM/Camel/Camel-spring integration? I wonder if blueprint deals better with what seems to be a race condition (Camel starting my routes too early).

Regards,

[iocanel]

Yes if using blueprint is an option you will have far less issues.

a) Blueprint will cause the bundle to fall into grace period until the component gets resolved.

b) You will not have other spring related issues, such as namespace handlers not being available etc.