fabric container dependency issues for FUSE 7.1.0

[jasonnh]

Hi,

I have 3 profiles that are the same except for one bundle.  The bundles that differ have the same imports (they are small and very similar).

I then have a container for each profile.

When I deploy everything two of the containers always work but one intermittently has a warning complaining it can not create route because it can not load data formats because camel jaxb is not on the classpath.

camel-jaxb is on the classpath because it is a feature of the profile in exactly the same way as the other two containers.

Executing:

update <bundle-id-of-bundle-with-route>

Makes everything work, i.e. the route is loaded correctly and everything works including jaxb.

The only difference I can see is the failing profile has an extra bundle in it that is very simple but I can not see any reason this profile should intermittently fail compared with the others.  The fact that update fixes it suggests a problem with the dependency loading.

Does anybody have any ideas on what may be wrong?

(FUSE 7.1.0, Windows 7, JDK 1.7.0_10 64 bit)

Thanks.

Edited by: jasonnh on Jan 10, 2013 4:36 PM

[davsclaus]

Are you using spring-dm or OSGi Blueprint, which I assume, is a Camel application, that is your custom bundle?

[jasonnh]

I just removed the extra bundle dependency mentioned above and still get the problem.

[jasonnh]

Sorry, I missed your comment.  I use OSGi blueprint for all bundles

[jasonnh]

I have found a strange workaround for this problem.

For the bundles that always work the Bundle-SymbolicName was hard coded to e.g. my-bundle-name-1, my-bundle-name-2.  For the one that was not working I had set it to:

<Bundle-SymbolicName>${project.groupId}_${project.artifactId}</Bundle-SymbolicName>

They all use the maven-bundle-plugin.

When I changed the Bundle-Symbolic name to hard coded, e.g. my-bundle-name-3 then I do not have the problem.

I do not think this is a build problem as I have cleaned maven repos, instances, data etc out and retried many times.

Does anybody know if the Bundle-SymbolicName can affect the order in which bundles are loaded?

Could a very long Bundle-SymbolicName cause problems?

[ffang]

Hi,

What's the Bundle-SymbolicName in the bundle which doesn't work?

You can use

osgi:headers bundle_id

to see it.

Freeman

[davsclaus]

Yeah and maybe also check the JAR file generated and look inside it, in the META-INF/MANIFEST.MF file.

Maybe those ${ } placeholders was not substituted and causing a problem for the osgi container with invalid data in MANIFEST.MF

[jasonnh]

What's the Bundle-SymbolicName in the bundle which doesn't work?

Using osgi:headers I can see it is correct, i.e. complete and the values have been substituted.

[jasonnh]

The manifest is also correct although the last two characters are on a new line prefix with a space (I think that is normal?)

[jasonnh]

Thanks to your help I think this is a problem with long Bundle-SymbolicName values.

When I reduce the length by using:

<Bundle-SymbolicName>TEMP_STRING_${project.artifactId}</Bundle-SymbolicName>

or

<Bundle-SymbolicName>${project.groupId}_TEMP_STRING</Bundle-SymbolicName>

or just

<Bundle-SymbolicName>TEMP_STRING</Bundle-SymbolicName>

Everything works.  It is only when the length of Bundle-SymbolicName means that it goes over more than one line in the manifest that I have problems.

osgi:headers always displays the correct values.

[davsclaus]

Ah the MANIFEST.MF is capped at 76 chars as a max limit.

So the maven-bundle-plugin honor this cap, and wrap the text on the new line.

I guess maybe the OSGi container (eg Apache Felix) has a bug/issue if the bundle name is longer.

[jasonnh]

I also tried with the hard coded long value rather then using maven variables and it does not work either.

Edited by: jasonnh on Jan 11, 2013 2:24 PM

[davsclaus]

I logged a ticket at Apache Felix

https://issues.apache.org/jira/browse/FELIX-3845

[davsclaus]

Do you have the bundle with that MANIFEST.MF file with that long name, that has the problem?

The Felix guys is asking for this sample so they can look into it. They cannot reproduce the issue.

[jasonnh]

davsclaus wrote:

Do you have the bundle with that MANIFEST.MF file with that long name, that has the problem?

The Felix guys is asking for this sample so they can look into it. They cannot reproduce the issue.

Thanks for adding the Felix bug.

Unfortunately, I have tried to recreate a simple standalone bundle for this problem which I can share but could not reproduce it when dependencies get simplified - but I have rested it and there is a problem that is solved by a short bundle symbolic name.

Based on what I have seen I think it might not be directly related to the bundle symbolic name but somehow the bundle symbolic name has an affect on the dependencies and a certain combination of dependencies causes this problem when creating a fabric container.  Just a guess though.