Yeah those kinds of errors are an irritation. One of the downsides to
Blueprint and I think OSGi in general is the somewhat obscure error
messages.

I haven't written my CBTS  in quite the way you have it so there may be
things I'm missing.  But if you have the properties for testing already
defined in the i4ip-order-publish-test-properties.xml is it necessary to
use the properties file and cfg?  Or are you simply trying to verify that
the properties override works? Also, I noticed that the properties file has
the full path name of src/test/resources which for the XML at least is not
required.  I'm not sure if it is necessary for loading properties. You
might want to put in a System.out.println or log statement in your setup to
see if it is coming in successfully.  I'm also unsure of how your
properties are getting associated with your contexts.  I suspect what you
want instead of in the @Befor setup is:

  @Override
    protected Properties useOverridePropertiesWithPropertiesComponent() {
        Properties props = new Properties();
        props.put("demo.sync", Boolean.TRUE.toString());
        return props;
    }

As far as I know you could then load your cfg file in at that point.

Have you tried running it in a full OSGi implementation?  CBTS uses PojoSR
which usually works fine but has some limitations.  It can't run multiple
contexts for example (although that doesn't appear to be the problem.)


Brad

On Fri, Sep 16, 2016 at 6:19 AM, Owain McGuire <owain@integration.technology
> wrote:

> Hi,
>
> I have a simple wire-tap root and I am unit testing it using
> CamelBlueprintTestSupport.  I can run the test and it passes but in the log
> I get:
>
> 2016-09-15 11:10:40,542 [int Extender: 2] ERROR BlueprintContainerImpl
>     - Unable to start blueprint container for bundle
> i4ip-order/1.0.0.SNAPSHOT
> org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
> to validate xml
> at org.apache.aries.blueprint.parser.Parser.validate(Parser.
> java:317)[org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(
> BlueprintContainerImpl.java:321)[org.apache.aries.
> blueprint.core-1.4.4.jar:1.4.4]
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(
> BlueprintContainerImpl.java:269)[org.apache.aries.
> blueprint.core-1.4.4.jar:1.4.4]
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)[:1.8.0_77]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
> at org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(
> ExecutorServiceWrapper.java:106)[org.apache.aries.
> blueprint.core-1.4.4.jar:1.4.4]
> at org.apache.aries.blueprint.utils.threading.impl.
> DiscardableRunnable.run(DiscardableRunnable.java:48)[
> org.apache.aries.blueprint.core-1.4.4.jar:1.4.4]
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:511)[:1.8.0_77]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_77]
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.
> java:180)[:1.8.0_77]
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_77]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)[:1.8.0_77]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)[:1.8.0_77]
> at java.lang.Thread.run(Thread.java:745)[:1.8.0_77]
>
> Full log here: https://gist.github.com/owain68/
> ea09215d7120dd8dc616e237a158a0f8
>
> I cannot for the life of me see what the problem is.  The route runs, the
> test passes.  Is it some sort of timing issue on starting the container,
> route or context.
>
> Any ideas where I should start looking for some more information?
>
> Thanks.
>
> O.
>
>
>

Reply via email to