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 <brad.john...@mediadriver.com>
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 <owain@integration.technology>
> 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.
>>
>
>

Reply via email to