camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Siepert (JIRA)" <>
Subject [jira] [Updated] (CAMEL-9313) CamelBlueprintTestSupport - timing problems with property placeholder
Date Thu, 12 Nov 2015 08:15:10 GMT


Andreas Siepert updated CAMEL-9313:
    Summary: CamelBlueprintTestSupport - timing problems with property placeholder  (was:
CamelBlueprintTestSupport )

> CamelBlueprintTestSupport - timing problems with property placeholder
> ---------------------------------------------------------------------
>                 Key: CAMEL-9313
>                 URL:
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-blueprint
>    Affects Versions: 2.15.4
>            Reporter: Andreas Siepert
>            Priority: Minor
> The bugfix CAMEL-8948 seems to make older timing problems related to property-placeholders
> To reproduce the problem i changed the test 
> org.apache.camel.test.blueprint.ConfigAdminNoReloadLoadConfigurationFileTest 
> from the component camel-test-blueprint a bit, respectively the context 
> "org/apache/camel/test/blueprint/configadmin-no-reload-loadfile.xml": 
> I added the trace Attribute to the camelContext 
> <camelContext xmlns="" 
> trace="{{tracing}}"> 
> and added also the property to the etc/stuff.cfg 
> tracing=true 
> Until 2.15.2 this worked fine. From 2.15.3 on the property cannot be 
> replaced any more.
> But, if setting a breakpoint in CamelBlueprintTestSupport#createBundleContext at loadConfigAdminConfigurationFile()
(Line 123 in 2.15.4) - the error occurs even in older versions like 2.14 - so the timing problem
seems to be there for a while but did not occur because the loading of the configAdminFile
seems to be faster than the event handling during service registration triggered by the code
some lines above.
> The issue can also be reproduced when replacing a property's String type 
> with int in the MyCoolBean class and setting its value by using the 
> placeholder like before but with an int value of course. The test run shows 
> that the placeholder ${..} will not be replaced and leads to a 
> NumberfFormatException. 
> The production code that is under test works fine in karaf. 

This message was sent by Atlassian JIRA

View raw message