camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Johnson <>
Subject Re: CamelBlueprintTestSupport doesn't like 6 directories deep
Date Wed, 07 Sep 2016 14:25:40 GMT
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.


On Wed, Sep 7, 2016 at 2:28 AM, sohrab <> 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:
> ops4j.pax.swissbox/pax-swissbox-tinybundles/1.3.2/org/ops4j/pax/swissbox/
> tinybundles/core/metadata/
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message