That's odd. I've never run into that problem and I have blueprint-properties.xml in almost all my bundles. Are your blueprint files all in the bundles? Also I have run into problems with the cm-property place holder name creating problems if the PID has character it doesn't expect. I think "-" created a hair pulling problem for me but don't quote me on that one. I do know that the cm PID was picky about the name. Usually I use a dot delimited version of the groupID/artifactID and that lets me override the properties by putting a groupID/artifactID.cfg file in the etc directory.
In all my bundles the blueprint files in the OSGI-INF/blueprint folder are named exactly the same. Since the bundles are loaded into their own classloaders they don't clash. The only thing that it does care about is the PID for the property-placeholder. Brad On Wed, Sep 7, 2016 at 2:28 AM, sohrab <sohrab.hosse...@gmail.com> wrote: > 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. >
