[ 
https://issues.apache.org/jira/browse/CAMEL-9313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033300#comment-15033300
 ] 

Andreas Siepert commented on CAMEL-9313:
----------------------------------------

Hi [~gzres] and sorry for the late response of mine. I was just writing the 
comment as yours came in...

I mentioned a second problem I attached a patch ({{camel-9313.patch}}) based on 
git branch {{camel-2.15.5}} which addresses the second problem and makes it 
visible. The problem is that the string of the propertyplaceholder is taken as 
the value which works fine for strings but not for int for example. Please have 
a look.

Stacktrace:
{code}
2015-12-01 08:57:37,415 [int Extender: 1] ERROR BlueprintContainerImpl         
- Unable to start blueprint container for bundle 
ConfigAdminLoadConfigurationFileTest/1.0.0
org.osgi.service.blueprint.container.ComponentDefinitionException: Error 
setting property: PropertyDescriptor <name: counter, getter: class 
org.apache.camel.test.blueprint.MyCoolBean.getCounter(), setter: [class 
org.apache.camel.test.blueprint.MyCoolBean.setCounter(int)]
        at 
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:939)
        at 
org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:905)
        at 
org.apache.aries.blueprint.container.BeanRecipe.setProperties(BeanRecipe.java:886)
        at 
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:820)
        at 
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
        at 
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at 
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
        at 
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:247)
        at 
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
        at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:682)
        at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:377)
        at 
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
        at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at 
org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(ExecutorServiceWrapper.java:106)
        at 
org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)
        at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
        at java.util.concurrent.FutureTask.run(FutureTask.java:262)
        at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
        at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
        at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NumberFormatException: For input string: "${counter}"
        at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
        at java.lang.Integer.parseInt(Integer.java:481)
        at java.lang.Integer.valueOf(Integer.java:582)
        at 
org.apache.aries.blueprint.container.AggregateConverter.convertFromString(AggregateConverter.java:281)
        at 
org.apache.aries.blueprint.container.AggregateConverter.convert(AggregateConverter.java:174)
        at 
org.apache.aries.blueprint.container.BlueprintRepository.convert(BlueprintRepository.java:402)
        at 
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.convert(ReflectionUtils.java:396)
        at 
org.apache.aries.blueprint.utils.ReflectionUtils$MethodPropertyDescriptor.internalSet(ReflectionUtils.java:630)
        at 
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:380)
        at 
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:937)
        ... 23 more
{code}



> CamelBlueprintTestSupport - timing problems with property placeholder
> ---------------------------------------------------------------------
>
>                 Key: CAMEL-9313
>                 URL: https://issues.apache.org/jira/browse/CAMEL-9313
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-blueprint
>    Affects Versions: 2.15.4
>            Reporter: Andreas Siepert
>            Assignee: Grzegorz Grzybek
>             Fix For: 2.16.2, 2.15.5, 2.17.0
>
>         Attachments: camel-9313.patch
>
>
> The bugfix CAMEL-8948 seems to make older timing problems related to 
> property-placeholders visible.
> 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:
> {code:xml}
> <camelContext xmlns="http://camel.apache.org/schema/blueprint"; 
> trace="{{tracing}}"> 
> {code}
> and added also the property to the etc/stuff.cfg 
> {code}
> tracing=true 
> {code}
> 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
(v6.3.4#6332)

Reply via email to