Yep, I have all those changes in my version of camel-test-blueprint. But anyway I think I narrowed down the problem.
It has nothing to do with Gradle vs. Maven. I have replicated it in both. Also the directory path matters but it is not as simple as more or fewer than 6. Basically this is a symptom of using multiple bluerprint XML files where one defines the cm:property-placeholder which is used by the other blueprint. Property-placeholders are treated differently during start-up. Unlike bean instantiation, that waits till all blueprint XMLs are parsed, property-replacement seem to happen right away. This means if a blueprint XML that uses a property-placeholder is loaded before the one that defines cm:property-placeholder, then the start-up fails. (This is the failure I get in my tests!) In Karaf container, the order of Blueprint XML start-up seems to be by the alphabetical order of the filenames so it is easy to get around this peculiarity. This does not seem to be true in Apache Felix Connect. If I have to take a guess, I'd say it is doing a Map.entrySet() to get blueprints in a loop, where the blueprint filename is the map's key and under-the-hood, its hash determines the order in the Set. Why do I think this? Because the created test-bundle uses the absolute path of blueprint XML for their names: blueprint--Users-sohrab-workspaces-client-service-payment-card-v1-target-resources-main-OSGI-INF-blueprint-2-camel-context.xml blueprint--Users-sohrab-workspaces-client-service-payment-card-v1-target-resources-main-OSGI-INF-blueprint-1-config.xml Where my original blueprint XML names were 1-config.xml and 2-camel-context.xml. This is why the directory path matters. Also why just simply changing "build" to "target" which is part of the name seem to change the hash enough to fix the order, sometimes. I have further verification of this because RawBuilder does a similar thing and actually logs it! So every time the blueprints are out of order in the RawBuilder log, I can also reproduce my problem: http://grepcode.com/file/repo1.maven.org/maven2/org.ops4j.pax.swissbox/pax-swissbox-tinybundles/1.3.2/org/ops4j/pax/swissbox/tinybundles/core/metadata/RawBuilder.java#77 I hate to change the production code (by combining all blueprints) just to cater for a buggy test framework. I've been looking through the Apache Felix Connect and Apache Aries code to figure out where this loading of blueprints is happening, to see if I can get around it. If anyone already knows, can you please point me to it? -- View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-doesn-t-like-6-directories-deep-tp5787192p5787264.html Sent from the Camel - Users mailing list archive at Nabble.com.
