That's one of the downsides to using the blueprint XML. I used to use it exclusively but have started the change to using the Java DSL and route builders and using blueprint just to bootstrap it. That keeps the blueprint headers very clean then - just blueprint itself and the cm for properties loading.
At least by going to the straight XML you've eliminated the properties loading as the source of the problem. Irritating I know. All I can say is been there, done that. I guess my next step if I were debugging this is to put all the XML in a single file and load it and see if you get the same problem. By the way, you may have already mentioned this but what version of CBTS are you using. I've started using the 2.17 version even with older versions of Camel. It is backwardly compatible and isn't compiled or used as part of the installation. But in earlier versions I found myself debugging the test and test framework itself as much as debugging the code. Earlier versions had race conditions (which you don't seem to be getting) and some other issues. Each subsequent version just got better and more stable. If you are just putting CBTS your POM with a test scope you should be able to run the 2.17 version and see if that helps. Perhaps not but at least you can eliminate that from the equation. Unfortunately I use Eclipse so don't know much about how IDEA works. Not that that should make much of a difference. Unless you have some old blueprint in your bundles in the headers I don't see why you would be running into that problem. I don't recall but what version of Camel did you say you are using? Then in your test you shouldn't need to load properties, only load the one blueprint file. No, you shouldn't have to do that but it if that doesn't work at least you'd there's something else wrong. When I get where I'm backed against the wall I'll commonly create dummy project using one of the archetypes and see if there's something fundamentally different about it. Wish I could be of more help. Brad <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"; xmlns:cm=" http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0 http://aries.apache.org/schemas/blueprint-cm/blueprint-cm-1.1.0.xsd "> //You'd have add defaults for any properties required. <cm:property-placeholder persistent-id="technology.integration.i4ip.order" update-strategy="reload"> <cm:default-properties> <cm:property name="foo" value="manchu"></cm:property> </cm:default-properties> </cm:property-placeholder> <camelContext id="i4ip-order-publish-test-context" xmlns=" http://camel.apache.org/schema/blueprint";> <route id="i4ip-order-publish-route"> <from uri="direct:i4ip-order-tap"/> <log loggingLevel="INFO" message="publishedMessage:${body}" id="publishedMessage"/> </route> </camelContext> </blueprint> @Override protected String getBlueprintDescriptor() { return "OSGI-INF/blueprint/i4ip-order-publish-route.xml"; } ///I haven't used isUsedAdviceWith in my tests so will refrain from any comment. @Override public boolean isUseAdviceWith() { return true; } @Test public void testMessageReceived() throws Exception { context.getRouteDefinition("i4ip-order-publish-route").adviceWith(context, new AdviceWithRouteBuilder() { @Override public void configure() throws Exception { replaceFromWith("direct:in"); weaveById("publishedMessage").after().to("mock:increment"); } }); final String BODY = "Hello"; MockEndpoint mockOut = getMockEndpoint("mock:increment"); mockOut.setExpectedMessageCount(1); context.start(); template.sendBody("direct:in", BODY); assertMockEndpointsSatisfied(); assertEquals(BODY, mockOut.getExchanges().get(0).getIn().getBody()); } On Mon, Sep 19, 2016 at 5:31 AM, owain <[email protected]> wrote: > Brad, > > Thank you for your response. Yes the default property in > cm:default-properties is over-ridden in the .cfg loaded in > loadConfigAdminConfigurationFile(). I was then logging {{foo}} in the > route. > > All of this appears to be working correctly. > > I took your advice and ripped out everything to do with properties and I > still get an "unable to validate xml" and test still passing. > > It is a bit infuriating since the route is now so simple and one would have > hoped the xml validation would have chucked out some more info on the > error. > > The xml validates correctly in IntelliJ IDEA. > > Progress of some sort: https://issues.apache.org/jira/browse/CAMEL-9923 > Not sure what I need to do or just leave it. I am running the test in IDEA > and not Karaf/Fuse. > > > But even with all the properties ripped out I am still getting this > problem. > Sounds like some old XML is lurking somewhere! > > > > > > -- > View this message in context: http://camel.465427.n5.nabble. > com/org-osgi-service-blueprint-container-ComponentDefinitionException- > Unable-to-validate-xml-tp5787642p5787724.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
