camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Siepert (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-9313) CamelBlueprintTestSupport - timing problems with property placeholder
Date Tue, 01 Dec 2015 08:06:10 GMT

    [ 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)

Mime
View raw message