Camel SAP + Spring - timing problem with configuration

There is a timing problem when running camel-sap component in Spring container. You get the following exception in JBoss Fuse:

    2015-04-29 14:13:58,776 | WARN  | ation-fuse/input | DocumentConverter                | ?                                   ? | 266 - org.fusesource.camel-sap - 6.2.0.redhat-110 | Failed to convert String to Document
    org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri 'http://sap.fusesource.org/idoc' not found. (file:/, 3, 524)
    	at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLLoadImpl.java:77)
    	at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:268)

wcollins wrote:

SapTransctionalIDocDestinationComponent not being properly initialized in the Spring container.

There is an inherent timing problem with configuring the SAP Components in both Blueprint and Spring frameworks. All of these components depend on the singleton bean sap-configuration (org.fusesource.camel.component.sap.SapConnectionConfiguration) being initialized first before the component beans. These components need to find valid connection configurations in the sap-configuration in order to initialize their endpoints properly. For reasons I can only speculate on this only seems to be an issue when running a spring container in fuse; in a standalone container I have not run into this issue. In Fuse the Blueprint container gets the initialization order correct; The Spring container however does not.

By adding the following line in the Spring configuration file I was able to resolve the initialization issue:

<bean class="org.fusesource.camel.component.sap.SapTransactionalIDocDestinationComponent" depends-on="sap-configuration"/>

I see this as a configuration problem and not necessarily a component problem; I don’t want to introduce Spring or Blueprint specific code into the components to solve this problem. This may be what we need to do to in a Spring configuration in all cases to bulletproof the timing issue. In the case of Blueprint however I am concerned we may have been just getting lucky and may have a latent problem in configuring the components in this environment. Since the Blueprint configurations don’t have the equivalent of a depends-on constraint, it is not clear what the best way to bulletproof this issue in Blueprint is.