Ah, that makes sense, I almost mentioned that CBTS uses PojoSR and not a real OSGi container but thought that was probably irrelevant. From what you say here though it does sound relevant. Just like you can't test with multiple camel contexts in CBTS.
On Wed, Sep 7, 2016 at 6:45 PM, sohrab <sohrab.hosse...@gmail.com> wrote: > Yeah it is hard one to replicate but once you do, it happens consistently. > > I actually got to the bottom of this. So according to the OSGi spec, the > "entries" inside a bundle are returned in the order they were originally > attached: > https://osgi.org/javadoc/r4v43/core/org/osgi/framework/ > Bundle.html#findEntries(java.lang.String, > java.lang.String, boolean) > > Apache Felix Connect respects this. However > org.ops4j.pax.swissbox.tinybundles.core.metadata.RawBuilder which does the > attaching, does so in a undeterministic manner by traversing a Set (see my > last post). > > Anyway, this behaviour leads to unreliable tests so I need to find a way > around it. Fortunately, Apache Aries respects "Bundle-Blueprint" header. So > if that header is provided, it will not ask Felix to go and search the > bundle for Blueprints. > > *My current, and hopefully definitive, work-around is to customise > CamelBlueprintHelper.createTestBundle() to add "Bundle-Blueprint" header > to > the manifest with a sorted list of blueprints.* > > > > -- > View this message in context: http://camel.465427.n5.nabble. > com/CamelBlueprintTestSupport-doesn-t-like-6-directories- > deep-tp5787192p5787333.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
