[jira] [Assigned] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-7488:
---
Assignee: Willem Jiang
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Assignee: Willem Jiang
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer.resolveProperties(BridgePropertyPlaceholderConfigurer.java:118)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:131)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:117)
at
org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1223)
at
org.apache.camel.model.ProcessorDefinition.resolvePropertyPlaceholders(ProcessorDefinition.java:571)
{noformat}
My current workaround was to specify propertyPlaceholder with empty location
in camelContext ...
{code:xml|title=camelContext.xml }
!-- same as above --
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
!-- location and id are mandatory --
camel:propertyPlaceholder id=stupidMandatoryId location=/
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027520#comment-14027520
]
Willem Jiang commented on CAMEL-7488:
-
Hi Sven,
I managed to reproduce the issue and find out PropertyPlaceholderConfigurer
know nothing about the util:constant as a property.
If have to use it in [a different
way|http://stackoverflow.com/questions/7309956/how-to-reference-constant-in-attribute-in-spring].
I did some work to enable the configuration of ignoreResourceNotFound, so you
don't need to addition camel:propertyPlaceholder to the camel context there,
the bridgePropertyPlaceHolder could be.
{code}
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=ignoreResourceNotFound value=true/
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
{code}
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer.resolveProperties(BridgePropertyPlaceholderConfigurer.java:118)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:131)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:117)
at
org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1223)
at
org.apache.camel.model.ProcessorDefinition.resolvePropertyPlaceholders(ProcessorDefinition.java:571)
{noformat}
My current workaround was to specify propertyPlaceholder with empty location
in camelContext ...
{code:xml|title=camelContext.xml }
!-- same as above --
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
!-- location and id are mandatory --
camel:propertyPlaceholder id=stupidMandatoryId location=/
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sven Nold updated CAMEL-7488:
-
Attachment: camel-test.zip
Files for new case
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Assignee: Willem Jiang
Attachments: camel-test.zip
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer.resolveProperties(BridgePropertyPlaceholderConfigurer.java:118)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:131)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:117)
at
org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1223)
at
org.apache.camel.model.ProcessorDefinition.resolvePropertyPlaceholders(ProcessorDefinition.java:571)
{noformat}
My current workaround was to specify propertyPlaceholder with empty location
in camelContext ...
{code:xml|title=camelContext.xml }
!-- same as above --
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
!-- location and id are mandatory --
camel:propertyPlaceholder id=stupidMandatoryId location=/
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027520#comment-14027520
]
Willem Jiang edited comment on CAMEL-7488 at 6/11/14 8:09 AM:
--
Hi Sven,
I managed to reproduce the issue and find out PropertyPlaceholderConfigurer
know nothing about the util:constant as a property.
You have to use it in [a different
way|http://stackoverflow.com/questions/7309956/how-to-reference-constant-in-attribute-in-spring].
I did some work to enable the configuration of ignoreResourceNotFound, so you
don't need to addition camel:propertyPlaceholder to the camel context there,
the bridgePropertyPlaceHolder could be.
{code}
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=ignoreResourceNotFound value=true/
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
{code}
was (Author: njiang):
Hi Sven,
I managed to reproduce the issue and find out PropertyPlaceholderConfigurer
know nothing about the util:constant as a property.
If have to use it in [a different
way|http://stackoverflow.com/questions/7309956/how-to-reference-constant-in-attribute-in-spring].
I did some work to enable the configuration of ignoreResourceNotFound, so you
don't need to addition camel:propertyPlaceholder to the camel context there,
the bridgePropertyPlaceHolder could be.
{code}
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=ignoreResourceNotFound value=true/
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
{code}
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Assignee: Willem Jiang
Attachments: camel-test.zip
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer.resolveProperties(BridgePropertyPlaceholderConfigurer.java:118)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:131)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:117)
at
org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1223)
at
org.apache.camel.model.ProcessorDefinition.resolvePropertyPlaceholders(ProcessorDefinition.java:571)
{noformat}
My current workaround was to specify propertyPlaceholder with empty location
in camelContext ...
{code:xml|title=camelContext.xml }
!-- same as above --
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
!-- location and id are mandatory --
camel:propertyPlaceholder id=stupidMandatoryId location=/
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7493) Expose the component options for Camel JDBC
[ https://issues.apache.org/jira/browse/CAMEL-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027531#comment-14027531 ] ASF GitHub Bot commented on CAMEL-7493: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/176 Fix for CAMEL-7493, Expose the component options for Camel JDBC You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7493 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/176.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #176 commit c2c90120b71e1a34ffe832d1e9e29f655247d30b Author: Kevin Earls ke...@kevinearls.com Date: 2014-06-11T08:05:00Z Fix for CAMEL-7493, Expose the component options for Camel JDBC Expose the component options for Camel JDBC --- Key: CAMEL-7493 URL: https://issues.apache.org/jira/browse/CAMEL-7493 Project: Camel Issue Type: Improvement Components: camel-jdbc Reporter: Kevin Earls Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027532#comment-14027532
]
Sven Nold commented on CAMEL-7488:
--
Hi Willem,
I already had that setting enabled, but even with 2.13-SNAPSHOT no luck.
If you enable tracing you can see lines like:
[pache.camel.spring.Main.main()] CamelContextFactoryBeanINFO Bridging
Camel and Spring property placeholder configurer with id:
bridgePropertyPlaceHolder
[pache.camel.spring.Main.main()] SpringCamelContext DEBUG Using
ComponentResolver: org.apache.camel.impl.DefaultComponentResolver@70ff4bfb to
resolve component with name: properties
[pache.camel.spring.Main.main()] DefaultListableBeanFactory TRACE No bean
named 'properties' found in
org.springframework.beans.factory.support.DefaultListableBeanFactory@4b37f3f9:
defining beans
[ag.isb.camel.Constants.CONSTANT_1,bridgePropertyPlaceHolder,template,consumerTemplate,camel-1:beanPostProcessor,camel-1];
root of factory hierarchy
[pache.camel.spring.Main.main()] DefaultComponentResolver DEBUG Found
component: properties in registry: null
[pache.camel.spring.Main.main()] ObjectHelper TRACE Loading
class: org.apache.camel.component.properties.PropertiesComponent using
classloader: java.net.URLClassLoader@154f6189
[pache.camel.spring.Main.main()] DefaultComponentResolver DEBUG Found
component: properties via type:
org.apache.camel.component.properties.PropertiesComponent via:
META-INF/services/org/apache/camel/component/properties
[pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Creating
instance of bean 'org.apache.camel.component.properties.PropertiesComponent'
[pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Returning
cached instance of singleton bean 'ag.isb.camel.Constants.CONSTANT_1'
[pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel
bean processing after initialization for bean: ag.isb.camel.Constants.CONSTANT_1
[pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG
Autowiring by type from bean name
'org.apache.camel.component.properties.PropertiesComponent' via constructor to
bean named 'ag.isb.camel.Constants.CONSTANT_1'
[pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Returning
cached instance of singleton bean 'ag.isb.camel.Constants.CONSTANT_1'
[pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel
bean processing after initialization for bean: ag.isb.camel.Constants.CONSTANT_1
[pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG
*Autowiring by type from bean name
'org.apache.camel.component.properties.PropertiesComponent' via constructor to
bean named 'ag.isb.camel.Constants.CONSTANT_1'*
[pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel
bean processing before initialization for bean:
org.apache.camel.component.properties.PropertiesComponent
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Assignee: Willem Jiang
Attachments: camel-test.zip
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
[jira] [Comment Edited] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[ https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027532#comment-14027532 ] Sven Nold edited comment on CAMEL-7488 at 6/11/14 8:13 AM: --- Hi Willem, I already had that setting enabled, but even with 2.13-SNAPSHOT no luck. If you enable tracing you can see lines like: [pache.camel.spring.Main.main()] CamelContextFactoryBeanINFO Bridging Camel and Spring property placeholder configurer with id: bridgePropertyPlaceHolder [pache.camel.spring.Main.main()] SpringCamelContext DEBUG Using ComponentResolver: org.apache.camel.impl.DefaultComponentResolver@70ff4bfb to resolve component with name: properties [pache.camel.spring.Main.main()] DefaultListableBeanFactory TRACE No bean named 'properties' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@4b37f3f9: defining beans [ag.isb.camel.Constants.CONSTANT_1,bridgePropertyPlaceHolder,template,consumerTemplate,camel-1:beanPostProcessor,camel-1]; root of factory hierarchy [pache.camel.spring.Main.main()] DefaultComponentResolver DEBUG Found component: properties in registry: null [pache.camel.spring.Main.main()] ObjectHelper TRACE Loading class: org.apache.camel.component.properties.PropertiesComponent using classloader: java.net.URLClassLoader@154f6189 [pache.camel.spring.Main.main()] DefaultComponentResolver DEBUG Found component: properties via type: org.apache.camel.component.properties.PropertiesComponent via: META-INF/services/org/apache/camel/component/properties [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Creating instance of bean 'org.apache.camel.component.properties.PropertiesComponent' [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Returning cached instance of singleton bean 'ag.isb.camel.Constants.CONSTANT_1' [pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel bean processing after initialization for bean: ag.isb.camel.Constants.CONSTANT_1 [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Autowiring by type from bean name 'org.apache.camel.component.properties.PropertiesComponent' via constructor to bean named 'ag.isb.camel.Constants.CONSTANT_1' [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Returning cached instance of singleton bean 'ag.isb.camel.Constants.CONSTANT_1' [pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel bean processing after initialization for bean: ag.isb.camel.Constants.CONSTANT_1 [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG *Autowiring by type from bean name 'org.apache.camel.component.properties.PropertiesComponent' via constructor to bean named 'ag.isb.camel.Constants.CONSTANT_1'* [pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel bean processing before initialization for bean: org.apache.camel.component.properties.PropertiesComponent Why is it doing that? was (Author: svennold): Hi Willem, I already had that setting enabled, but even with 2.13-SNAPSHOT no luck. If you enable tracing you can see lines like: [pache.camel.spring.Main.main()] CamelContextFactoryBeanINFO Bridging Camel and Spring property placeholder configurer with id: bridgePropertyPlaceHolder [pache.camel.spring.Main.main()] SpringCamelContext DEBUG Using ComponentResolver: org.apache.camel.impl.DefaultComponentResolver@70ff4bfb to resolve component with name: properties [pache.camel.spring.Main.main()] DefaultListableBeanFactory TRACE No bean named 'properties' found in org.springframework.beans.factory.support.DefaultListableBeanFactory@4b37f3f9: defining beans [ag.isb.camel.Constants.CONSTANT_1,bridgePropertyPlaceHolder,template,consumerTemplate,camel-1:beanPostProcessor,camel-1]; root of factory hierarchy [pache.camel.spring.Main.main()] DefaultComponentResolver DEBUG Found component: properties in registry: null [pache.camel.spring.Main.main()] ObjectHelper TRACE Loading class: org.apache.camel.component.properties.PropertiesComponent using classloader: java.net.URLClassLoader@154f6189 [pache.camel.spring.Main.main()] DefaultComponentResolver DEBUG Found component: properties via type: org.apache.camel.component.properties.PropertiesComponent via: META-INF/services/org/apache/camel/component/properties [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Creating instance of bean 'org.apache.camel.component.properties.PropertiesComponent' [pache.camel.spring.Main.main()] DefaultListableBeanFactory DEBUG Returning cached instance of singleton bean 'ag.isb.camel.Constants.CONSTANT_1' [pache.camel.spring.Main.main()] DefaultCamelBeanPostProcessor TRACE Camel bean processing after initialization for bean:
[jira] [Commented] (CAMEL-7493) Expose the component options for Camel JDBC
[ https://issues.apache.org/jira/browse/CAMEL-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027542#comment-14027542 ] ASF GitHub Bot commented on CAMEL-7493: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/176 Expose the component options for Camel JDBC --- Key: CAMEL-7493 URL: https://issues.apache.org/jira/browse/CAMEL-7493 Project: Camel Issue Type: Improvement Components: camel-jdbc Reporter: Kevin Earls Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7495) parameter json schema should support object types
Claus Ibsen created CAMEL-7495: -- Summary: parameter json schema should support object types Key: CAMEL-7495 URL: https://issues.apache.org/jira/browse/CAMEL-7495 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.1 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.13.2, 2.14.0 For example this DataSource option https://github.com/apache/camel/blob/master/components/camel-jdbc/src/main/java/org/apache/camel/component/jdbc/JdbcEndpoint.java#L42 We need to expose that in the json schema as an object type. And for configuring endpoint using uris, you would use a # registry lookup. eg dataSource=#myDataSource. But the schema needs to support this option -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027551#comment-14027551
]
Willem Jiang commented on CAMEL-7488:
-
I just set the constant Property into the BridgePropertyPlaceholderConfigurer
just like this
{code}
util:constant id=test
static-field=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurerTest.CONSTANT/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=properties
props
!-- reference the constant value in a property--
prop key=testProperty#{test}/prop
/props
/property
property name=ignoreResourceNotFound value=true/
property name=locations
list
valueclasspath:someplaceToOverride/value
/list
/property
/bean
{code}
I think you can also wire the Properties that way.
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Assignee: Willem Jiang
Attachments: camel-test.zip
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer.resolveProperties(BridgePropertyPlaceholderConfigurer.java:118)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:131)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:117)
at
org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1223)
at
org.apache.camel.model.ProcessorDefinition.resolvePropertyPlaceholders(ProcessorDefinition.java:571)
{noformat}
My current workaround was to specify propertyPlaceholder with empty location
in camelContext ...
{code:xml|title=camelContext.xml }
!-- same as above --
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
!-- location and id are mandatory --
camel:propertyPlaceholder id=stupidMandatoryId location=/
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7496) BridgePropertyPlaceholderConfigurer should take ignoreResourceNotFound into consideration when it loads the property files
Willem Jiang created CAMEL-7496: --- Summary: BridgePropertyPlaceholderConfigurer should take ignoreResourceNotFound into consideration when it loads the property files Key: CAMEL-7496 URL: https://issues.apache.org/jira/browse/CAMEL-7496 Project: Camel Issue Type: Improvement Components: camel-spring Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.14.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7488) PropertiesComponent gets initialized by util:constant
[
https://issues.apache.org/jira/browse/CAMEL-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027555#comment-14027555
]
Sven Nold commented on CAMEL-7488:
--
Sorry but the main problem/issue is that PropertiesComponent autowires that
constants.
I cannot get rid off that (util:)constant(s) because they're referenced else
where, which I cannot change.
Is there any way to remove this auto magic of using these constants as part of
the PropertiesComponent (constructor) initialization. I couldn't find any
@Autowired annotation.
PropertiesComponent gets initialized by util:constant
-
Key: CAMEL-7488
URL: https://issues.apache.org/jira/browse/CAMEL-7488
Project: Camel
Issue Type: Bug
Components: camel-core, camel-spring
Affects Versions: 2.13.0, 2.13.1
Reporter: Sven Nold
Assignee: Willem Jiang
Attachments: camel-test.zip
Using BridgePropertyPlaceholderConfigurer Spring util constant namespace
to reference a static field, the Properties Component gets initialized with
this constant.
{code:xml|title=camelContext.xml }
util:constant static-field=anypackage.CONSTANT_1/
bean id=bridgePropertyPlaceHolder
class=org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer
property name=locations
list
valueclasspath:test.properties/value
/list
/property
/bean
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
Will produce following Stacktrace (constant contained 'This will be loaded
as location; but I am simply a constant'):
{noformat}
Caused by: java.io.FileNotFoundException: Properties file This will be
loaded as location; but I am simply a constant not found in classpath
at
org.apache.camel.component.properties.DefaultPropertiesResolver.loadPropertiesFromClasspath(DefaultPropertiesResolver.java:96)
at
org.apache.camel.component.properties.DefaultPropertiesResolver.resolveProperties(DefaultPropertiesResolver.java:55)
at
org.apache.camel.spring.spi.BridgePropertyPlaceholderConfigurer.resolveProperties(BridgePropertyPlaceholderConfigurer.java:118)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:131)
at
org.apache.camel.component.properties.PropertiesComponent.parseUri(PropertiesComponent.java:117)
at
org.apache.camel.impl.DefaultCamelContext.resolvePropertyPlaceholders(DefaultCamelContext.java:1223)
at
org.apache.camel.model.ProcessorDefinition.resolvePropertyPlaceholders(ProcessorDefinition.java:571)
{noformat}
My current workaround was to specify propertyPlaceholder with empty location
in camelContext ...
{code:xml|title=camelContext.xml }
!-- same as above --
camel:camelContext xmlns=http://camel.apache.org/schema/spring;
!-- location and id are mandatory --
camel:propertyPlaceholder id=stupidMandatoryId location=/
camel:route
camel:from uri=direct://ignore /
camel:setBody
camel:simple{{testProperty}}/camel:simple
/camel:setBody
camel:to uri=mock://ignore /
/camel:route
/camel:camelContext
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7497) Duplicate classes
Paul D Johe created CAMEL-7497:
--
Summary: Duplicate classes
Key: CAMEL-7497
URL: https://issues.apache.org/jira/browse/CAMEL-7497
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 2.13.1
Reporter: Paul D Johe
Priority: Minor
It looks like there are duplicate classes between the camel-test and
camel-test-spring artifacts:
{code}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicateClasses failed
with message:
Duplicate classes found:
Found in:
org.apache.camel:camel-test:jar:2.13.1:test
org.apache.camel:camel-test-spring:jar:2.13.1:test
Duplicate classes:
org/apache/camel/test/junit4/CamelTestSupport$1.class
org/apache/camel/test/junit4/CamelTestSupport$4.class
org/apache/camel/test/junit4/CamelTestSupport$2.class
org/apache/camel/test/junit4/CamelTestSupport$DebugBreakpoint.class
org/apache/camel/test/junit4/LanguageTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport.class
org/apache/camel/test/junit4/TestSupport.class
org/apache/camel/test/junit4/ExchangeTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport$3.class
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7498) Expose the component options for Camel SQL
Kevin Earls created CAMEL-7498: -- Summary: Expose the component options for Camel SQL Key: CAMEL-7498 URL: https://issues.apache.org/jira/browse/CAMEL-7498 Project: Camel Issue Type: Bug Reporter: Kevin Earls Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7498) Expose the component options for Camel SQL
[ https://issues.apache.org/jira/browse/CAMEL-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027691#comment-14027691 ] ASF GitHub Bot commented on CAMEL-7498: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/177 Fix for CAMEL-7498. Most of this was already done, just adding a test h... ...ere You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7498 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/177.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #177 commit b66df8b76357fd4f292a40f0d4c12b49dc88d50c Author: Kevin Earls ke...@kevinearls.com Date: 2014-06-11T12:22:41Z Fix for CAMEL-7498. Most of this was already done, just adding a test here Expose the component options for Camel SQL -- Key: CAMEL-7498 URL: https://issues.apache.org/jira/browse/CAMEL-7498 Project: Camel Issue Type: Bug Reporter: Kevin Earls Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CAMEL-7497) Duplicate classes
[
https://issues.apache.org/jira/browse/CAMEL-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027715#comment-14027715
]
Willem Jiang edited comment on CAMEL-7497 at 6/11/14 1:09 PM:
--
This is caused by camel-spring-test and camel-test are exports the same package
of org.apache.camel.test.junit4.
As the org.apache.camel.test.junit4.CamelSpringJUnit4ClassRunner and
org.apache.camel.test.junit4.CamelSpringTestSupport were derecated since
camel-2.11.0, it should be safe for us to remove them in camel-2.14.0 now.
was (Author: njiang):
This is caused by camel-spring-test and camel-test are exports the same package
of org.apache.camel.test.junit4.
As the org.apache.camel.test.junit4.CamelSpringJUnit4ClassRunner and
org.apache.camel.test.junit4.CamelSpringTestSupport were derecated since
camel-2.11.0, it should be safe for us to remove them now.
Duplicate classes
--
Key: CAMEL-7497
URL: https://issues.apache.org/jira/browse/CAMEL-7497
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 2.13.1
Reporter: Paul D Johe
Priority: Minor
It looks like there are duplicate classes between the camel-test and
camel-test-spring artifacts:
{code}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicateClasses
failed with message:
Duplicate classes found:
Found in:
org.apache.camel:camel-test:jar:2.13.1:test
org.apache.camel:camel-test-spring:jar:2.13.1:test
Duplicate classes:
org/apache/camel/test/junit4/CamelTestSupport$1.class
org/apache/camel/test/junit4/CamelTestSupport$4.class
org/apache/camel/test/junit4/CamelTestSupport$2.class
org/apache/camel/test/junit4/CamelTestSupport$DebugBreakpoint.class
org/apache/camel/test/junit4/LanguageTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport.class
org/apache/camel/test/junit4/TestSupport.class
org/apache/camel/test/junit4/ExchangeTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport$3.class
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7497) Duplicate classes
[
https://issues.apache.org/jira/browse/CAMEL-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027715#comment-14027715
]
Willem Jiang commented on CAMEL-7497:
-
This is caused by camel-spring-test and camel-test are exports the same package
of org.apache.camel.test.junit4.
As the org.apache.camel.test.junit4.CamelSpringJUnit4ClassRunner and
org.apache.camel.test.junit4.CamelSpringTestSupport were derecated since
camel-2.11.0, it should be safe for us to remove them now.
Duplicate classes
--
Key: CAMEL-7497
URL: https://issues.apache.org/jira/browse/CAMEL-7497
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 2.13.1
Reporter: Paul D Johe
Priority: Minor
It looks like there are duplicate classes between the camel-test and
camel-test-spring artifacts:
{code}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicateClasses
failed with message:
Duplicate classes found:
Found in:
org.apache.camel:camel-test:jar:2.13.1:test
org.apache.camel:camel-test-spring:jar:2.13.1:test
Duplicate classes:
org/apache/camel/test/junit4/CamelTestSupport$1.class
org/apache/camel/test/junit4/CamelTestSupport$4.class
org/apache/camel/test/junit4/CamelTestSupport$2.class
org/apache/camel/test/junit4/CamelTestSupport$DebugBreakpoint.class
org/apache/camel/test/junit4/LanguageTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport.class
org/apache/camel/test/junit4/TestSupport.class
org/apache/camel/test/junit4/ExchangeTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport$3.class
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7497) Duplicate classes
[
https://issues.apache.org/jira/browse/CAMEL-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7497.
-
Resolution: Fixed
Fix Version/s: 2.14.0
Duplicate classes
--
Key: CAMEL-7497
URL: https://issues.apache.org/jira/browse/CAMEL-7497
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 2.13.1
Reporter: Paul D Johe
Assignee: Willem Jiang
Priority: Minor
Fix For: 2.14.0
It looks like there are duplicate classes between the camel-test and
camel-test-spring artifacts:
{code}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicateClasses
failed with message:
Duplicate classes found:
Found in:
org.apache.camel:camel-test:jar:2.13.1:test
org.apache.camel:camel-test-spring:jar:2.13.1:test
Duplicate classes:
org/apache/camel/test/junit4/CamelTestSupport$1.class
org/apache/camel/test/junit4/CamelTestSupport$4.class
org/apache/camel/test/junit4/CamelTestSupport$2.class
org/apache/camel/test/junit4/CamelTestSupport$DebugBreakpoint.class
org/apache/camel/test/junit4/LanguageTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport.class
org/apache/camel/test/junit4/TestSupport.class
org/apache/camel/test/junit4/ExchangeTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport$3.class
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CAMEL-7497) Duplicate classes
[
https://issues.apache.org/jira/browse/CAMEL-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-7497:
---
Assignee: Willem Jiang
Duplicate classes
--
Key: CAMEL-7497
URL: https://issues.apache.org/jira/browse/CAMEL-7497
Project: Camel
Issue Type: Bug
Components: camel-test
Affects Versions: 2.13.1
Reporter: Paul D Johe
Assignee: Willem Jiang
Priority: Minor
Fix For: 2.14.0
It looks like there are duplicate classes between the camel-test and
camel-test-spring artifacts:
{code}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanDuplicateClasses
failed with message:
Duplicate classes found:
Found in:
org.apache.camel:camel-test:jar:2.13.1:test
org.apache.camel:camel-test-spring:jar:2.13.1:test
Duplicate classes:
org/apache/camel/test/junit4/CamelTestSupport$1.class
org/apache/camel/test/junit4/CamelTestSupport$4.class
org/apache/camel/test/junit4/CamelTestSupport$2.class
org/apache/camel/test/junit4/CamelTestSupport$DebugBreakpoint.class
org/apache/camel/test/junit4/LanguageTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport.class
org/apache/camel/test/junit4/TestSupport.class
org/apache/camel/test/junit4/ExchangeTestSupport.class
org/apache/camel/test/junit4/CamelTestSupport$3.class
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7499) Expose the component options for Camel Mail
Kevin Earls created CAMEL-7499: -- Summary: Expose the component options for Camel Mail Key: CAMEL-7499 URL: https://issues.apache.org/jira/browse/CAMEL-7499 Project: Camel Issue Type: Improvement Reporter: Kevin Earls Priority: Minor Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7499) Expose the component options for Camel Mail
[ https://issues.apache.org/jira/browse/CAMEL-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027853#comment-14027853 ] ASF GitHub Bot commented on CAMEL-7499: --- GitHub user kevinearls opened a pull request: https://github.com/apache/camel/pull/178 Fix for CAMEL-7499, Expose the component options for Camel Mail You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinearls/camel CAMEL-7499 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/178.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #178 commit cc4e7785f82e2e9cd524c2b155a56f6722bee2d0 Author: Kevin Earls ke...@kevinearls.com Date: 2014-06-11T15:07:21Z Fix for CAMEL-7499, Expose the component options for Camel Mail Expose the component options for Camel Mail --- Key: CAMEL-7499 URL: https://issues.apache.org/jira/browse/CAMEL-7499 Project: Camel Issue Type: Improvement Reporter: Kevin Earls Priority: Minor Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7500) Concurrent modification of exchange during retry leads to futher processing of failed messages
Bob Browning created CAMEL-7500: --- Summary: Concurrent modification of exchange during retry leads to futher processing of failed messages Key: CAMEL-7500 URL: https://issues.apache.org/jira/browse/CAMEL-7500 Project: Camel Issue Type: Bug Components: camel-netty Affects Versions: 2.13.1 Reporter: Bob Browning When a exception occurs on a netty TCP channel such as ChanelClosedException then there are two invocations of the producer callback. If there is a redelivery handler configured this causes either two threads to be added to the scheduled thread-pool which then compete or in the more common case the first invocation adds the redelivery thread but in doing so clears the exception from the exchange such that when the subsequent callback invocation occurs it see's the event as a success and continues routing of the exchange. Note this also seems to be a cause of negative inflight messages on the route. The first callback invocation occurs in the ChannelFutureListener which is the usual case. The second callback invocation which comes from the ClientChannelHandler registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-7500: Attachment: NettyRedeliveryTest.java Concurrent modification of exchange during retry leads to futher processing of failed messages -- Key: CAMEL-7500 URL: https://issues.apache.org/jira/browse/CAMEL-7500 Project: Camel Issue Type: Bug Components: camel-netty Affects Versions: 2.13.1 Reporter: Bob Browning Attachments: NettyRedeliveryTest.java When a exception occurs on a netty TCP channel such as ChanelClosedException then there are two invocations of the producer callback. If there is a redelivery handler configured this causes either two threads to be added to the scheduled thread-pool which then compete or in the more common case the first invocation adds the redelivery thread but in doing so clears the exception from the exchange such that when the subsequent callback invocation occurs it see's the event as a success and continues routing of the exchange. Note this also seems to be a cause of negative inflight messages on the route. The first callback invocation occurs in the ChannelFutureListener which is the usual case. The second callback invocation which comes from the ClientChannelHandler registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-7500: Summary: Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages (was: Concurrent modification of exchange during retry leads to futher processing of failed messages) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages -- Key: CAMEL-7500 URL: https://issues.apache.org/jira/browse/CAMEL-7500 Project: Camel Issue Type: Bug Components: camel-netty Affects Versions: 2.13.1 Reporter: Bob Browning Attachments: NettyRedeliveryTest.java When a exception occurs on a netty TCP channel such as ChanelClosedException then there are two invocations of the producer callback. If there is a redelivery handler configured this causes either two threads to be added to the scheduled thread-pool which then compete or in the more common case the first invocation adds the redelivery thread but in doing so clears the exception from the exchange such that when the subsequent callback invocation occurs it see's the event as a success and continues routing of the exchange. Note this also seems to be a cause of negative inflight messages on the route. The first callback invocation occurs in the ChannelFutureListener which is the usual case. The second callback invocation which comes from the ClientChannelHandler registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-7500: Attachment: NettyRedeliveryTest.java Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages -- Key: CAMEL-7500 URL: https://issues.apache.org/jira/browse/CAMEL-7500 Project: Camel Issue Type: Bug Components: camel-netty Affects Versions: 2.13.1 Reporter: Bob Browning Attachments: NettyRedeliveryTest.java When a exception occurs on a netty TCP channel such as ChanelClosedException then there are two invocations of the producer callback. If there is a redelivery handler configured this causes either two threads to be added to the scheduled thread-pool which then compete or in the more common case the first invocation adds the redelivery thread but in doing so clears the exception from the exchange such that when the subsequent callback invocation occurs it see's the event as a success and continues routing of the exchange. Note this also seems to be a cause of negative inflight messages on the route. The first callback invocation occurs in the ChannelFutureListener which is the usual case. The second callback invocation which comes from the ClientChannelHandler registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-7500: Attachment: (was: NettyRedeliveryTest.java) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages -- Key: CAMEL-7500 URL: https://issues.apache.org/jira/browse/CAMEL-7500 Project: Camel Issue Type: Bug Components: camel-netty Affects Versions: 2.13.1 Reporter: Bob Browning Attachments: NettyRedeliveryTest.java When a exception occurs on a netty TCP channel such as ChanelClosedException then there are two invocations of the producer callback. If there is a redelivery handler configured this causes either two threads to be added to the scheduled thread-pool which then compete or in the more common case the first invocation adds the redelivery thread but in doing so clears the exception from the exchange such that when the subsequent callback invocation occurs it see's the event as a success and continues routing of the exchange. Note this also seems to be a cause of negative inflight messages on the route. The first callback invocation occurs in the ChannelFutureListener which is the usual case. The second callback invocation which comes from the ClientChannelHandler registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7499) Expose the component options for Camel Mail
[ https://issues.apache.org/jira/browse/CAMEL-7499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028131#comment-14028131 ] ASF GitHub Bot commented on CAMEL-7499: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/178 Expose the component options for Camel Mail --- Key: CAMEL-7499 URL: https://issues.apache.org/jira/browse/CAMEL-7499 Project: Camel Issue Type: Improvement Reporter: Kevin Earls Priority: Minor Expose the component options for Camel JDBC as has already been done for camel-core components and selected others such as jms / ftp / twitter etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7492) xpath/xquery - Allow to suppress exceptions when used as predicate
[
https://issues.apache.org/jira/browse/CAMEL-7492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028376#comment-14028376
]
Christian Müller commented on CAMEL-7492:
-
Why not simply:
{code}
xpath/foo/bar/xpath
{code}
or
{code}
choice
whenxpath/foo/bar/xpath
to uri=jms:fooOrBar/
/when
...
{code}
?
I think it's because of the backwards compatibility, but is there a real use
case where the user would like to receive the exception instead of true/false?
May be we should introduce the change in the behavior (being not backwards
compatible) but providing a better default behavior.
xpath/xquery - Allow to suppress exceptions when used as predicate
--
Key: CAMEL-7492
URL: https://issues.apache.org/jira/browse/CAMEL-7492
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-saxon
Reporter: Claus Ibsen
Priority: Minor
Fix For: Future
See
http://stackoverflow.com/questions/24124015/apache-camel-xpath-routing
If you use a content based router, and have different kind of xml coming in,
you may want to ignore any exceptions, if a xpath expression fails to
evaluate as the xml does not fit that format.
So if we have
{code}
xpath ignoreException=true/foo/bar/xpath
{code}
eg a new attribute to set a flag to ignore exceptions. Though naming is hard,
so maybe there is a better name for the attribute.
Related is also the validate eip, but I dont think we can use that as an
expression/predicate: http://camel.apache.org/validate
Otherwise we could do something like this; which may be even better as then
it works with any Camel expression/predicate.
{code:xml}
choice
whenvalidatexpath/foo/bar/xpath/validate
to uri=jms:fooOrBar/
/when
...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7501) Only one ZooKeeperRoutePolicy possible
Scott Stults created CAMEL-7501: --- Summary: Only one ZooKeeperRoutePolicy possible Key: CAMEL-7501 URL: https://issues.apache.org/jira/browse/CAMEL-7501 Project: Camel Issue Type: Bug Components: camel-zookeeper Affects Versions: 2.12.3 Reporter: Scott Stults If two ZooKeeperRoutePolicy's are created and used in separate routes, only one leader election route gets created. This effectively nullifies the route policy for the second route, meaning it works regardless of leadership status (even on the other route). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CAMEL-7487) Create an archetype and code generation plugins to generate Camel Components that wrap some API
[ https://issues.apache.org/jira/browse/CAMEL-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde reopened CAMEL-7487: - Simplify generated code, hiding all the API method model magic, call to helpers etc. and expose various interception points in the method invocation flow as protected methods. Create an archetype and code generation plugins to generate Camel Components that wrap some API --- Key: CAMEL-7487 URL: https://issues.apache.org/jira/browse/CAMEL-7487 Project: Camel Issue Type: Improvement Components: camel-core, tooling Affects Versions: 2.12.4 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Fix For: 2.12.4 The Facebook component took the approach of creating an API model for the Facebook4J API and mapping its methods and parameters to its URI endpoint using API independent code. This reduced the number of lines of code in the component significantly while still being able to expose every operation in the Facebook4J API. This approach can be made generic, so that an API model can be created for any Java Class/Interface that needs to be wrapped by a Camel component. This model can either be manually written in a signature file similar to the output from the 'javap' command with a method per line with parameter names, or automatically generated by parsing Javadoc. The method and parameter names then can be mapped to the component's URI paths and URI parameters/options. The component could use a map of API name path prefixes to several APIs it supports/implements. An API-component archetype could generate boilerplate code that uses the code-generation plugins that can generate models. The component developer then just has to populate with code for actually creating the API proxies. Even integration tests can be generated (which use nulls for test values) for producer endpoints for the component, and the developer just needs to complete the skeleton test with actual values. The producer endpoint code can be easily copied and modified to write consumer tests. Components may want to customize consumer processing based on the consumer capabilities or features of the wrapped API/technology, which can be easily done by modifying the generated consumer code. This micro-framework for generating Camel components that use API models, will significantly reduce the amount of effort and time it takes to wrap any API and expose it as a Camel component. The framework is also useful in situations where an API is not readily available, but one can be written as a Java POJO or Interface and then wrapped as an API component. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7487) Create an archetype and code generation plugins to generate Camel Components that wrap some API
[ https://issues.apache.org/jira/browse/CAMEL-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028782#comment-14028782 ] ASF GitHub Bot commented on CAMEL-7487: --- GitHub user dhirajsb opened a pull request: https://github.com/apache/camel/pull/179 CAMEL-7487 Simplify generated code, add support for excluding endpoint configuration properties You can merge this pull request into a Git repository by running: $ git pull https://github.com/dhirajsb/camel camel-7487 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/179.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #179 commit 37541d2e31ce640f77298c599bc050bc80166902 Author: Dhiraj Bokde dhira...@yahoo.com Date: 2014-06-11T23:12:50Z Refactored API Endpoint, Consumer and Producer to extrac Abstract classes in camel-core, simplifying generated code, minor fixes in route test template, added two parameter method in sample API commit 4b0381f2983343a4d47a5f3fc3df0ed8427991bc Author: Dhiraj Bokde dhira...@yahoo.com Date: 2014-06-11T23:54:04Z Added support for excluding generated endpoint config properties by name or type Create an archetype and code generation plugins to generate Camel Components that wrap some API --- Key: CAMEL-7487 URL: https://issues.apache.org/jira/browse/CAMEL-7487 Project: Camel Issue Type: Improvement Components: camel-core, tooling Affects Versions: 2.12.4 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Fix For: 2.12.4 The Facebook component took the approach of creating an API model for the Facebook4J API and mapping its methods and parameters to its URI endpoint using API independent code. This reduced the number of lines of code in the component significantly while still being able to expose every operation in the Facebook4J API. This approach can be made generic, so that an API model can be created for any Java Class/Interface that needs to be wrapped by a Camel component. This model can either be manually written in a signature file similar to the output from the 'javap' command with a method per line with parameter names, or automatically generated by parsing Javadoc. The method and parameter names then can be mapped to the component's URI paths and URI parameters/options. The component could use a map of API name path prefixes to several APIs it supports/implements. An API-component archetype could generate boilerplate code that uses the code-generation plugins that can generate models. The component developer then just has to populate with code for actually creating the API proxies. Even integration tests can be generated (which use nulls for test values) for producer endpoints for the component, and the developer just needs to complete the skeleton test with actual values. The producer endpoint code can be easily copied and modified to write consumer tests. Components may want to customize consumer processing based on the consumer capabilities or features of the wrapped API/technology, which can be easily done by modifying the generated consumer code. This micro-framework for generating Camel components that use API models, will significantly reduce the amount of effort and time it takes to wrap any API and expose it as a Camel component. The framework is also useful in situations where an API is not readily available, but one can be written as a Java POJO or Interface and then wrapped as an API component. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CAMEL-7487) Create an archetype and code generation plugins to generate Camel Components that wrap some API
[ https://issues.apache.org/jira/browse/CAMEL-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028781#comment-14028781 ] Dhiraj Bokde edited comment on CAMEL-7487 at 6/12/14 3:14 AM: -- Simplify generated code, hiding all the API method model magic, call to helpers etc. and expose various interception points in the method invocation flow as protected methods. Also add support for excluding arguments based on name or type from being exposed through endpoint configuration to hide internal/component provided arguments. was (Author: dhirajsb): Simplify generated code, hiding all the API method model magic, call to helpers etc. and expose various interception points in the method invocation flow as protected methods. Create an archetype and code generation plugins to generate Camel Components that wrap some API --- Key: CAMEL-7487 URL: https://issues.apache.org/jira/browse/CAMEL-7487 Project: Camel Issue Type: Improvement Components: camel-core, tooling Affects Versions: 2.12.4 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Fix For: 2.12.4 The Facebook component took the approach of creating an API model for the Facebook4J API and mapping its methods and parameters to its URI endpoint using API independent code. This reduced the number of lines of code in the component significantly while still being able to expose every operation in the Facebook4J API. This approach can be made generic, so that an API model can be created for any Java Class/Interface that needs to be wrapped by a Camel component. This model can either be manually written in a signature file similar to the output from the 'javap' command with a method per line with parameter names, or automatically generated by parsing Javadoc. The method and parameter names then can be mapped to the component's URI paths and URI parameters/options. The component could use a map of API name path prefixes to several APIs it supports/implements. An API-component archetype could generate boilerplate code that uses the code-generation plugins that can generate models. The component developer then just has to populate with code for actually creating the API proxies. Even integration tests can be generated (which use nulls for test values) for producer endpoints for the component, and the developer just needs to complete the skeleton test with actual values. The producer endpoint code can be easily copied and modified to write consumer tests. Components may want to customize consumer processing based on the consumer capabilities or features of the wrapped API/technology, which can be easily done by modifying the generated consumer code. This micro-framework for generating Camel components that use API models, will significantly reduce the amount of effort and time it takes to wrap any API and expose it as a Camel component. The framework is also useful in situations where an API is not readily available, but one can be written as a Java POJO or Interface and then wrapped as an API component. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7487) Create an archetype and code generation plugins to generate Camel Components that wrap some API
[ https://issues.apache.org/jira/browse/CAMEL-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028795#comment-14028795 ] ASF GitHub Bot commented on CAMEL-7487: --- Github user asfgit closed the pull request at: https://github.com/apache/camel/pull/179 Create an archetype and code generation plugins to generate Camel Components that wrap some API --- Key: CAMEL-7487 URL: https://issues.apache.org/jira/browse/CAMEL-7487 Project: Camel Issue Type: Improvement Components: camel-core, tooling Affects Versions: 2.12.4 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Fix For: 2.12.4 The Facebook component took the approach of creating an API model for the Facebook4J API and mapping its methods and parameters to its URI endpoint using API independent code. This reduced the number of lines of code in the component significantly while still being able to expose every operation in the Facebook4J API. This approach can be made generic, so that an API model can be created for any Java Class/Interface that needs to be wrapped by a Camel component. This model can either be manually written in a signature file similar to the output from the 'javap' command with a method per line with parameter names, or automatically generated by parsing Javadoc. The method and parameter names then can be mapped to the component's URI paths and URI parameters/options. The component could use a map of API name path prefixes to several APIs it supports/implements. An API-component archetype could generate boilerplate code that uses the code-generation plugins that can generate models. The component developer then just has to populate with code for actually creating the API proxies. Even integration tests can be generated (which use nulls for test values) for producer endpoints for the component, and the developer just needs to complete the skeleton test with actual values. The producer endpoint code can be easily copied and modified to write consumer tests. Components may want to customize consumer processing based on the consumer capabilities or features of the wrapped API/technology, which can be easily done by modifying the generated consumer code. This micro-framework for generating Camel components that use API models, will significantly reduce the amount of effort and time it takes to wrap any API and expose it as a Camel component. The framework is also useful in situations where an API is not readily available, but one can be written as a Java POJO or Interface and then wrapped as an API component. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7487) Create an archetype and code generation plugins to generate Camel Components that wrap a third party API
[ https://issues.apache.org/jira/browse/CAMEL-7487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7487: Summary: Create an archetype and code generation plugins to generate Camel Components that wrap a third party API (was: Create an archetype and code generation plugins to generate Camel Components that wrap some API) Create an archetype and code generation plugins to generate Camel Components that wrap a third party API Key: CAMEL-7487 URL: https://issues.apache.org/jira/browse/CAMEL-7487 Project: Camel Issue Type: Improvement Components: camel-core, tooling Affects Versions: 2.12.4 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Fix For: 2.12.4 The Facebook component took the approach of creating an API model for the Facebook4J API and mapping its methods and parameters to its URI endpoint using API independent code. This reduced the number of lines of code in the component significantly while still being able to expose every operation in the Facebook4J API. This approach can be made generic, so that an API model can be created for any Java Class/Interface that needs to be wrapped by a Camel component. This model can either be manually written in a signature file similar to the output from the 'javap' command with a method per line with parameter names, or automatically generated by parsing Javadoc. The method and parameter names then can be mapped to the component's URI paths and URI parameters/options. The component could use a map of API name path prefixes to several APIs it supports/implements. An API-component archetype could generate boilerplate code that uses the code-generation plugins that can generate models. The component developer then just has to populate with code for actually creating the API proxies. Even integration tests can be generated (which use nulls for test values) for producer endpoints for the component, and the developer just needs to complete the skeleton test with actual values. The producer endpoint code can be easily copied and modified to write consumer tests. Components may want to customize consumer processing based on the consumer capabilities or features of the wrapped API/technology, which can be easily done by modifying the generated consumer code. This micro-framework for generating Camel components that use API models, will significantly reduce the amount of effort and time it takes to wrap any API and expose it as a Camel component. The framework is also useful in situations where an API is not readily available, but one can be written as a Java POJO or Interface and then wrapped as an API component. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7492) xpath/xquery - Allow to suppress exceptions when used as predicate
[
https://issues.apache.org/jira/browse/CAMEL-7492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028846#comment-14028846
]
Claus Ibsen commented on CAMEL-7492:
You want the current behavior with the exception if the input message is
invalid, such as not XML or a different XML that does not match the `form of
xpath expression`.
But there are times where you may want to relax that and dont care, and just
want the CBR to evaluate the next when/otherwise. eg sorta like a tryWhen .
xpath/xquery - Allow to suppress exceptions when used as predicate
--
Key: CAMEL-7492
URL: https://issues.apache.org/jira/browse/CAMEL-7492
Project: Camel
Issue Type: Improvement
Components: camel-core, camel-saxon
Reporter: Claus Ibsen
Priority: Minor
Fix For: Future
See
http://stackoverflow.com/questions/24124015/apache-camel-xpath-routing
If you use a content based router, and have different kind of xml coming in,
you may want to ignore any exceptions, if a xpath expression fails to
evaluate as the xml does not fit that format.
So if we have
{code}
xpath ignoreException=true/foo/bar/xpath
{code}
eg a new attribute to set a flag to ignore exceptions. Though naming is hard,
so maybe there is a better name for the attribute.
Related is also the validate eip, but I dont think we can use that as an
expression/predicate: http://camel.apache.org/validate
Otherwise we could do something like this; which may be even better as then
it works with any Camel expression/predicate.
{code:xml}
choice
whenvalidatexpath/foo/bar/xpath/validate
to uri=jms:fooOrBar/
/when
...
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7502) camel-elastichsearch - starts up an instance even though IP specified
Claus Ibsen created CAMEL-7502: -- Summary: camel-elastichsearch - starts up an instance even though IP specified Key: CAMEL-7502 URL: https://issues.apache.org/jira/browse/CAMEL-7502 Project: Camel Issue Type: Bug Components: camel-elasticsearch Affects Versions: 2.13.1 Reporter: Claus Ibsen Fix For: 2.13.2, 2.14.0 See nabble http://camel.465427.n5.nabble.com/camel-elasticsearch-component-starts-up-an-instance-even-though-IP-specified-tp5751825.html -- This message was sent by Atlassian JIRA (v6.2#6252)
