PS I've likely missed something in that XML sample because I don't see a direct:in nor the increment route. It's more just how I end up backing out until I can figure out the source of my problems - other than visiting a shrink.
On Mon, Sep 19, 2016 at 1:21 PM, Brad Johnson <[email protected]> wrote: > 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-ComponentDefinition >> Exception-Unable-to-validate-xml-tp5787642p5787724.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> > >
