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-ComponentDefinitionException-
> Unable-to-validate-xml-tp5787642p5787724.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Reply via email to