By the way, if your XML for the properties has default values for all the
required properties then even an error in loading the properties file will
mean the test will run fine (which is what you seem to be seeing.) One way
to check that is to temporarily comment out one of the default properties
in the XML required for your test to run.  If it then throws the same
exception your seeing and another one about not finding the property that
you commented out you'll know that your properties aren't loading correctly
or getting set on the test container (for whatever reason.)

You may have already done this but I'd take an incremental approach.  Try
commenting out the loading of the properties loading and make sure you have
all the default properties necessary.  Then run your test with just the XML
and make sure you don't get a validation error in the loading of the XML.
If you don't see that error you'll know that the problem is related to the
properties file.  But the error specifically says it is associated with the
XML.  So personally I'd make sure all the XML is ironed out first.  Then
attempt the properties.

If you're just trying to verify the override on the properties I'm fairly
certain that the mechanism used by CBTS is not the same as the one used
karaf/felix.

Brad

On Fri, Sep 16, 2016 at 1:00 PM, Brad Johnson <brad.john...@mediadriver.com>
wrote:

> 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.jav
>> a: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.blu
>> eprint.core-1.4.4.jar:1.4.4]
>> at org.apache.aries.blueprint.container.BlueprintContainerImpl.
>> run(BlueprintContainerImpl.java:269)[org.apache.aries.blu
>> eprint.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.blu
>> eprint.core-1.4.4.jar:1.4.4]
>> at org.apache.aries.blueprint.utils.threading.impl.DiscardableR
>> unnable.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$ScheduledFu
>> tureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_77]
>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFu
>> tureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_77]
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool
>> Executor.java:1142)[:1.8.0_77]
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo
>> lExecutor.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/ea09215d7120dd8dc616e2
>> 37a158a0f8
>>
>> 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