You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Andreas Siepert (JIRA)" <ji...@apache.org> on 2015/12/01 09:06:10 UTC
[jira] [Commented] (CAMEL-9313) CamelBlueprintTestSupport - timing
problems with property placeholder
[ 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)