[jira] [Created] (CAMEL-6634) JMX Agent - Allow to use property placeholders for statisticsLevel option
Claus Ibsen created CAMEL-6634: -- Summary: JMX Agent - Allow to use property placeholders for statisticsLevel option Key: CAMEL-6634 URL: https://issues.apache.org/jira/browse/CAMEL-6634 Project: Camel Issue Type: Improvement Components: camel-blueprint, camel-spring Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.12.0 This is the only option which doesnt today support property placeholders. We should add support for that on this option too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6634) JMX Agent - Allow to use property placeholders for statisticsLevel option
[ https://issues.apache.org/jira/browse/CAMEL-6634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6634. Resolution: Fixed JMX Agent - Allow to use property placeholders for statisticsLevel option - Key: CAMEL-6634 URL: https://issues.apache.org/jira/browse/CAMEL-6634 Project: Camel Issue Type: Improvement Components: camel-blueprint, camel-spring Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.12.0 This is the only option which doesnt today support property placeholders. We should add support for that on this option too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6635) PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled
Claus Ibsen created CAMEL-6635: -- Summary: PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled Key: CAMEL-6635 URL: https://issues.apache.org/jira/browse/CAMEL-6635 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.0 Due the recent SPI which allows to plugin a different scheduler we can improved this and use a non scheduled thread pool, which avoids the suspend/resume and run for at least one poll hack we have today in the codebase. Instead we can use a regular thread pool as the scheduler, and then submit the task on demand when receive() is called on the PollingConsumer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6636) HttpClient 4.3 sets a global port to be re-used by endpoints that do not have port defined
Per Jørgen Walstrøm created CAMEL-6636:
--
Summary: HttpClient 4.3 sets a global port to be re-used by
endpoints that do not have port defined
Key: CAMEL-6636
URL: https://issues.apache.org/jira/browse/CAMEL-6636
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 2.11.0
Reporter: Per Jørgen Walstrøm
two routes within the same camel-context are configured as shown below. They
post to two different URLs; route1 stating no port (implicitly, this should
mean port 80) and route2 stating port 81.
During start-up, the following is logged
{{
12:06:52.316 [main] INFO o.a.c.component.http4.HttpComponent - Registering
PLAIN scheme http4 on port 80
12:06:52.372 [main] INFO o.a.c.component.http4.HttpComponent - Registering
PLAIN scheme http4 on port 81
}}
when the post is actually done, the following is logged
{{
12:18:46.437 [Camel (d-2) thread #8 - Threads] DEBUG
o.a.h.i.c.DefaultClientConnectionOperator - Connecting to bar.com:81
12:18:46.465 [Camel (d-2) thread #7 - Threads] DEBUG
o.a.h.i.c.DefaultClientConnectionOperator - Connecting to example.com:81
}}
Port 81 is re-used also for route1. There are some workarounds for this:
- the order of the route configuration is significant. If route2 was configured
before route1, everything would work ok
- if we explicitly set port 80 in route1 (example.com:80), everything works fine
The DefaultClientConnectionOperator.openConnection() finds the port from the
registry.getScheme(target.getSchemeName()) which returns port 81. This is used
as default port if no port is set.
The DefaultClientConnectionOperator is deprecated in 4.3, you may want to use
PoolingHttpClientConnectionManager (don't know if this solves the problem,
though).
Or maybe this is not a Camel problem but a HttpClient bug?
{quote}
from(activemq:topic:foo)
.routeId(route1)
.threads()
.setHeader(HTTP_METHOD, constant(POST))
.to(http4://example.com);
from(activemq:topic:foo)
.routeId(route2)
.threads()
.setHeader(HTTP_METHOD, constant(POST))
.to(http4://bar.com:81);
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6636) HttpClient 4.3 sets a global port to be re-used by endpoints that do not have port defined
[
https://issues.apache.org/jira/browse/CAMEL-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-6636.
Resolution: Duplicate
Assignee: Claus Ibsen
Duplicate of CAMEL-6078
HttpClient 4.3 sets a global port to be re-used by endpoints that do not have
port defined
--
Key: CAMEL-6636
URL: https://issues.apache.org/jira/browse/CAMEL-6636
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 2.11.0
Reporter: Per Jørgen Walstrøm
Assignee: Claus Ibsen
two routes within the same camel-context are configured as shown below. They
post to two different URLs; route1 stating no port (implicitly, this should
mean port 80) and route2 stating port 81.
During start-up, the following is logged
{{
12:06:52.316 [main] INFO o.a.c.component.http4.HttpComponent - Registering
PLAIN scheme http4 on port 80
12:06:52.372 [main] INFO o.a.c.component.http4.HttpComponent - Registering
PLAIN scheme http4 on port 81
}}
when the post is actually done, the following is logged
{{
12:18:46.437 [Camel (d-2) thread #8 - Threads] DEBUG
o.a.h.i.c.DefaultClientConnectionOperator - Connecting to bar.com:81
12:18:46.465 [Camel (d-2) thread #7 - Threads] DEBUG
o.a.h.i.c.DefaultClientConnectionOperator - Connecting to example.com:81
}}
Port 81 is re-used also for route1. There are some workarounds for this:
- the order of the route configuration is significant. If route2 was
configured before route1, everything would work ok
- if we explicitly set port 80 in route1 (example.com:80), everything works
fine
The DefaultClientConnectionOperator.openConnection() finds the port from the
registry.getScheme(target.getSchemeName()) which returns port 81. This is
used as default port if no port is set.
The DefaultClientConnectionOperator is deprecated in 4.3, you may want to use
PoolingHttpClientConnectionManager (don't know if this solves the problem,
though).
Or maybe this is not a Camel problem but a HttpClient bug?
{quote}
from(activemq:topic:foo)
.routeId(route1)
.threads()
.setHeader(HTTP_METHOD, constant(POST))
.to(http4://example.com);
from(activemq:topic:foo)
.routeId(route2)
.threads()
.setHeader(HTTP_METHOD, constant(POST))
.to(http4://bar.com:81);
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6622) Support XML Encryption 1.1 features in the camel-xmlsecurity component
[ https://issues.apache.org/jira/browse/CAMEL-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739501#comment-13739501 ] Claus Ibsen commented on CAMEL-6622: Ah okay so mgfAlgorithm should not be configurable? Support XML Encryption 1.1 features in the camel-xmlsecurity component -- Key: CAMEL-6622 URL: https://issues.apache.org/jira/browse/CAMEL-6622 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.12.0 Attachments: camel-6622.patch This task is to support XML Encryption 1.1 functionality in the camel-xmlsecurity component. This includes: a) Support for the GCM versions of AES b) Support for SHA 1 with the RSA OAEP algorithm c) Support for MGF algorithms with SHA 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6622) Support XML Encryption 1.1 features in the camel-xmlsecurity component
[ https://issues.apache.org/jira/browse/CAMEL-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739508#comment-13739508 ] Colm O hEigeartaigh commented on CAMEL-6622: No it should be configurable, although I don't expect it to be used very often. My question was more abstract: in general in Camel if adding new configuration options for a DataFormat, must it always be added to the constructor of the DataFormat in camel-core? Or will a setX suffice if it is not a commonly used option? Thanks, Colm. Support XML Encryption 1.1 features in the camel-xmlsecurity component -- Key: CAMEL-6622 URL: https://issues.apache.org/jira/browse/CAMEL-6622 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.12.0 Attachments: camel-6622.patch This task is to support XML Encryption 1.1 functionality in the camel-xmlsecurity component. This includes: a) Support for the GCM versions of AES b) Support for SHA 1 with the RSA OAEP algorithm c) Support for MGF algorithms with SHA 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6622) Support XML Encryption 1.1 features in the camel-xmlsecurity component
[ https://issues.apache.org/jira/browse/CAMEL-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739512#comment-13739512 ] Claus Ibsen commented on CAMEL-6622: Using getter/setter is the preferred way. Most others dont have ctr parameters. The contributor of the xmlsecurity used ctrl as well and hence why they are there today. Support XML Encryption 1.1 features in the camel-xmlsecurity component -- Key: CAMEL-6622 URL: https://issues.apache.org/jira/browse/CAMEL-6622 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.12.0 Attachments: camel-6622.patch This task is to support XML Encryption 1.1 functionality in the camel-xmlsecurity component. This includes: a) Support for the GCM versions of AES b) Support for SHA 1 with the RSA OAEP algorithm c) Support for MGF algorithms with SHA 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6622) Support XML Encryption 1.1 features in the camel-xmlsecurity component
[ https://issues.apache.org/jira/browse/CAMEL-6622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739513#comment-13739513 ] Claus Ibsen commented on CAMEL-6622: I am applying the patch right now on master. Fell free to help updating the docs at http://camel.apache.org/xmlsecurity-dataformat.html Support XML Encryption 1.1 features in the camel-xmlsecurity component -- Key: CAMEL-6622 URL: https://issues.apache.org/jira/browse/CAMEL-6622 Project: Camel Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 2.12.0 Attachments: camel-6622.patch This task is to support XML Encryption 1.1 functionality in the camel-xmlsecurity component. This includes: a) Support for the GCM versions of AES b) Support for SHA 1 with the RSA OAEP algorithm c) Support for MGF algorithms with SHA 1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6635) PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled
[ https://issues.apache.org/jira/browse/CAMEL-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6635. Resolution: Fixed PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled --- Key: CAMEL-6635 URL: https://issues.apache.org/jira/browse/CAMEL-6635 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.0 Due the recent SPI which allows to plugin a different scheduler we can improved this and use a non scheduled thread pool, which avoids the suspend/resume and run for at least one poll hack we have today in the codebase. Instead we can use a regular thread pool as the scheduler, and then submit the task on demand when receive() is called on the PollingConsumer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6636) HttpClient 4 sets a global port to be re-used by endpoints that do not have port defined
[
https://issues.apache.org/jira/browse/CAMEL-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Per Jørgen Walstrøm updated CAMEL-6636:
---
Summary: HttpClient 4 sets a global port to be re-used by endpoints that do
not have port defined (was: HttpClient 4.3 sets a global port to be re-used by
endpoints that do not have port defined)
HttpClient 4 sets a global port to be re-used by endpoints that do not have
port defined
Key: CAMEL-6636
URL: https://issues.apache.org/jira/browse/CAMEL-6636
Project: Camel
Issue Type: Bug
Components: camel-http
Affects Versions: 2.11.0
Reporter: Per Jørgen Walstrøm
Assignee: Claus Ibsen
two routes within the same camel-context are configured as shown below. They
post to two different URLs; route1 stating no port (implicitly, this should
mean port 80) and route2 stating port 81.
During start-up, the following is logged
{{
12:06:52.316 [main] INFO o.a.c.component.http4.HttpComponent - Registering
PLAIN scheme http4 on port 80
12:06:52.372 [main] INFO o.a.c.component.http4.HttpComponent - Registering
PLAIN scheme http4 on port 81
}}
when the post is actually done, the following is logged
{{
12:18:46.437 [Camel (d-2) thread #8 - Threads] DEBUG
o.a.h.i.c.DefaultClientConnectionOperator - Connecting to bar.com:81
12:18:46.465 [Camel (d-2) thread #7 - Threads] DEBUG
o.a.h.i.c.DefaultClientConnectionOperator - Connecting to example.com:81
}}
Port 81 is re-used also for route1. There are some workarounds for this:
- the order of the route configuration is significant. If route2 was
configured before route1, everything would work ok
- if we explicitly set port 80 in route1 (example.com:80), everything works
fine
The DefaultClientConnectionOperator.openConnection() finds the port from the
registry.getScheme(target.getSchemeName()) which returns port 81. This is
used as default port if no port is set.
The DefaultClientConnectionOperator is deprecated in 4.3, you may want to use
PoolingHttpClientConnectionManager (don't know if this solves the problem,
though).
Or maybe this is not a Camel problem but a HttpClient bug?
{quote}
from(activemq:topic:foo)
.routeId(route1)
.threads()
.setHeader(HTTP_METHOD, constant(POST))
.to(http4://example.com);
from(activemq:topic:foo)
.routeId(route2)
.threads()
.setHeader(HTTP_METHOD, constant(POST))
.to(http4://bar.com:81);
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-3215) @PropertyInjected - An annotation to inject a property from Camel properties
[
https://issues.apache.org/jira/browse/CAMEL-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739517#comment-13739517
]
Claus Ibsen commented on CAMEL-3215:
See also SO
http://stackoverflow.com/questions/18210717/apache-camel-fields-injection/18229762#18229762
@PropertyInjected - An annotation to inject a property from Camel properties
Key: CAMEL-3215
URL: https://issues.apache.org/jira/browse/CAMEL-3215
Project: Camel
Issue Type: New Feature
Components: camel-core
Affects Versions: 2.4.0
Reporter: Claus Ibsen
Priority: Minor
Fix For: Future
This is just an idea. Suppose you have a RouteBuilder in Java DSL and you
need a timeout value to be defined in a properties file
{code}
aggregateTimeout=2
{code}
And then you want to use this timeout value in the RouteBuilder
{code}
from(xxx).aggregate(header(group),
myStrategy).completionTimeout(timeout).to(zzz);
{code}
The problem is that the DSL requires the timeout to be an integer because
that makes sense. So we can't use the property placeholder directly in the
DSL as its a String type.
eg. the following is *not* possible
{code}
from(xxx).aggregate(header(group),
myStrategy).completionTimeout({{aggregationTimeout}}).to(zzz);
{code}
What we may need is to inject the timeout value in the RouteBuilder in a field
{code}
@PropertyInjected(aggregationTimeout)
private int timeout;
{code}
The @PropertyInjected annotation tells Camel to go look for the
aggregationTimeout property and convert the value to the same type of the
field, which is an int.
Now you can use that value in the Java DSL
There may be other or standard annotations/injections possible.
Any though?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-3215) @PropertyInjected - An annotation to inject a property from Camel properties
[
https://issues.apache.org/jira/browse/CAMEL-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-3215:
--
Assignee: Claus Ibsen
@PropertyInjected - An annotation to inject a property from Camel properties
Key: CAMEL-3215
URL: https://issues.apache.org/jira/browse/CAMEL-3215
Project: Camel
Issue Type: New Feature
Components: camel-core
Affects Versions: 2.4.0
Reporter: Claus Ibsen
Assignee: Claus Ibsen
Priority: Minor
Fix For: Future
This is just an idea. Suppose you have a RouteBuilder in Java DSL and you
need a timeout value to be defined in a properties file
{code}
aggregateTimeout=2
{code}
And then you want to use this timeout value in the RouteBuilder
{code}
from(xxx).aggregate(header(group),
myStrategy).completionTimeout(timeout).to(zzz);
{code}
The problem is that the DSL requires the timeout to be an integer because
that makes sense. So we can't use the property placeholder directly in the
DSL as its a String type.
eg. the following is *not* possible
{code}
from(xxx).aggregate(header(group),
myStrategy).completionTimeout({{aggregationTimeout}}).to(zzz);
{code}
What we may need is to inject the timeout value in the RouteBuilder in a field
{code}
@PropertyInjected(aggregationTimeout)
private int timeout;
{code}
The @PropertyInjected annotation tells Camel to go look for the
aggregationTimeout property and convert the value to the same type of the
field, which is an int.
Now you can use that value in the Java DSL
There may be other or standard annotations/injections possible.
Any though?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6637) BeanIO Data Format logs at WARN level for conditions are ignored in configuration
Sam Lewis created CAMEL-6637: Summary: BeanIO Data Format logs at WARN level for conditions are ignored in configuration Key: CAMEL-6637 URL: https://issues.apache.org/jira/browse/CAMEL-6637 Project: Camel Issue Type: Bug Components: camel-beanio Affects Versions: 2.12.1 Reporter: Sam Lewis Priority: Minor The BeanIODataFormat has the properties: - ignoreUnidentifiedRecords - ignoreUnexpectedRecords - ignoreInvalidRecords In the error handler, these issues are always logged at WARN level regardless of the above settings. I would say that if the developer is happy to ignore these issues by explicitly configuring them to ignored, when these issues are encountered they should be logged at DEBUG level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6637) BeanIO Data Format logs at WARN level for conditions are ignored in configuration
[ https://issues.apache.org/jira/browse/CAMEL-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Lewis updated CAMEL-6637: - Attachment: CAMEL-6637.patch BeanIO Data Format logs at WARN level for conditions are ignored in configuration - Key: CAMEL-6637 URL: https://issues.apache.org/jira/browse/CAMEL-6637 Project: Camel Issue Type: Bug Components: camel-beanio Affects Versions: 2.12.1 Reporter: Sam Lewis Priority: Minor Attachments: CAMEL-6637.patch The BeanIODataFormat has the properties: - ignoreUnidentifiedRecords - ignoreUnexpectedRecords - ignoreInvalidRecords In the error handler, these issues are always logged at WARN level regardless of the above settings. I would say that if the developer is happy to ignore these issues by explicitly configuring them to ignored, when these issues are encountered they should be logged at DEBUG level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6637) BeanIO Data Format logs at WARN level for conditions are ignored in configuration
[ https://issues.apache.org/jira/browse/CAMEL-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Lewis updated CAMEL-6637: - Patch Info: Patch Available BeanIO Data Format logs at WARN level for conditions are ignored in configuration - Key: CAMEL-6637 URL: https://issues.apache.org/jira/browse/CAMEL-6637 Project: Camel Issue Type: Bug Components: camel-beanio Affects Versions: 2.12.1 Reporter: Sam Lewis Priority: Minor Attachments: CAMEL-6637.patch The BeanIODataFormat has the properties: - ignoreUnidentifiedRecords - ignoreUnexpectedRecords - ignoreInvalidRecords In the error handler, these issues are always logged at WARN level regardless of the above settings. I would say that if the developer is happy to ignore these issues by explicitly configuring them to ignored, when these issues are encountered they should be logged at DEBUG level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6637) BeanIO Data Format logs at WARN level for conditions ignored in configuration
[ https://issues.apache.org/jira/browse/CAMEL-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Lewis updated CAMEL-6637: - Summary: BeanIO Data Format logs at WARN level for conditions ignored in configuration (was: BeanIO Data Format logs at WARN level for conditions are ignored in configuration) BeanIO Data Format logs at WARN level for conditions ignored in configuration - Key: CAMEL-6637 URL: https://issues.apache.org/jira/browse/CAMEL-6637 Project: Camel Issue Type: Bug Components: camel-beanio Affects Versions: 2.12.1 Reporter: Sam Lewis Priority: Minor Attachments: CAMEL-6637.patch The BeanIODataFormat has the properties: - ignoreUnidentifiedRecords - ignoreUnexpectedRecords - ignoreInvalidRecords In the error handler, these issues are always logged at WARN level regardless of the above settings. I would say that if the developer is happy to ignore these issues by explicitly configuring them to ignored, when these issues are encountered they should be logged at DEBUG level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-6637) BeanIO Data Format logs at WARN level for conditions ignored in configuration
[ https://issues.apache.org/jira/browse/CAMEL-6637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6637: -- Assignee: Claus Ibsen BeanIO Data Format logs at WARN level for conditions ignored in configuration - Key: CAMEL-6637 URL: https://issues.apache.org/jira/browse/CAMEL-6637 Project: Camel Issue Type: Bug Components: camel-beanio Affects Versions: 2.12.1 Reporter: Sam Lewis Assignee: Claus Ibsen Priority: Minor Attachments: CAMEL-6637.patch The BeanIODataFormat has the properties: - ignoreUnidentifiedRecords - ignoreUnexpectedRecords - ignoreInvalidRecords In the error handler, these issues are always logged at WARN level regardless of the above settings. I would say that if the developer is happy to ignore these issues by explicitly configuring them to ignored, when these issues are encountered they should be logged at DEBUG level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CAMEL-6635) PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled
[ https://issues.apache.org/jira/browse/CAMEL-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reopened CAMEL-6635: PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled --- Key: CAMEL-6635 URL: https://issues.apache.org/jira/browse/CAMEL-6635 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.0 Due the recent SPI which allows to plugin a different scheduler we can improved this and use a non scheduled thread pool, which avoids the suspend/resume and run for at least one poll hack we have today in the codebase. Instead we can use a regular thread pool as the scheduler, and then submit the task on demand when receive() is called on the PollingConsumer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6635) PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled
[ https://issues.apache.org/jira/browse/CAMEL-6635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6635. Resolution: Unresolved Darn the polling consumer logic wasn't too well equipped for this kind. Had to revert to use the old way to allow picking up late files that arrives later when the poll starts. PollingConsumer from a scheduled consumer such as file/ftp can use a regular thread pool instead of being scheduled --- Key: CAMEL-6635 URL: https://issues.apache.org/jira/browse/CAMEL-6635 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.0 Due the recent SPI which allows to plugin a different scheduler we can improved this and use a non scheduled thread pool, which avoids the suspend/resume and run for at least one poll hack we have today in the codebase. Instead we can use a regular thread pool as the scheduler, and then submit the task on demand when receive() is called on the PollingConsumer API. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6471) CxfPayload - Dont output the body in toString if streaming mode
[ https://issues.apache.org/jira/browse/CAMEL-6471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740031#comment-13740031 ] Aki Yoshida commented on CAMEL-6471: Hi Claus, Will you be integrating this fix to 2.11.x? Without this fix, toString() called somewhere or even during debugging is turning a non-dom source body into a dom source body. So I think, it would be very nice to have this fix integrated to the lower codelines. regards, aki CxfPayload - Dont output the body in toString if streaming mode --- Key: CAMEL-6471 URL: https://issues.apache.org/jira/browse/CAMEL-6471 Project: Camel Issue Type: Improvement Components: camel-cxf Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.12.0 org.apache.camel.component.cxf.CxfPayload#toString This forces outputting the body even if its streaming mode. This is bad. We should not load the stream into memory. There is already good logging support by the log component where you can turn on|off logging streams etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6638) create a camel component for vertx
james strachan created CAMEL-6638: - Summary: create a camel component for vertx Key: CAMEL-6638 URL: https://issues.apache.org/jira/browse/CAMEL-6638 Project: Camel Issue Type: New Feature Reporter: james strachan Assignee: james strachan -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6638) create a camel component for vertx
[ https://issues.apache.org/jira/browse/CAMEL-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan updated CAMEL-6638: -- Fix Version/s: 2.12.0 create a camel component for vertx -- Key: CAMEL-6638 URL: https://issues.apache.org/jira/browse/CAMEL-6638 Project: Camel Issue Type: New Feature Reporter: james strachan Assignee: james strachan Fix For: 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6638) create a camel component for vertx
[ https://issues.apache.org/jira/browse/CAMEL-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740170#comment-13740170 ] james strachan commented on CAMEL-6638: --- documentation is here: https://cwiki.apache.org/confluence/display/CAMEL/Vertx create a camel component for vertx -- Key: CAMEL-6638 URL: https://issues.apache.org/jira/browse/CAMEL-6638 Project: Camel Issue Type: New Feature Reporter: james strachan Assignee: james strachan Fix For: 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-6638) create a camel component for vertx
[ https://issues.apache.org/jira/browse/CAMEL-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved CAMEL-6638. --- Resolution: Fixed create a camel component for vertx -- Key: CAMEL-6638 URL: https://issues.apache.org/jira/browse/CAMEL-6638 Project: Camel Issue Type: New Feature Reporter: james strachan Assignee: james strachan Fix For: 2.12.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6545) seda producer - Add option to fail for non existing queue
[
https://issues.apache.org/jira/browse/CAMEL-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Posta updated CAMEL-6545:
---
Attachment: Patch_for_https___issues_apache_org_jira_browse_CAMEL-6545.patch
Claus, can you give me feedback on this when you get a chance?
seda producer - Add option to fail for non existing queue
-
Key: CAMEL-6545
URL: https://issues.apache.org/jira/browse/CAMEL-6545
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Priority: Minor
Fix For: Future
Attachments:
Patch_for_https___issues_apache_org_jira_browse_CAMEL-6545.patch
See
http://stackoverflow.com/questions/17457231/in-apache-camel-how-can-i-receive-an-error-if-an-endpoint-doesnt-exist
It would be nice if we can configure a seda producer endpoint to fail if
sending to a queue with no consumers at runtime, when the producer tries to
send to the queue.
.to(seda:foo?failIfNoConsumers=true)
Maybe the name should be {{failIfNoConsumers}} ?
For example the direct component has an exception
DirectConsumerNotAvailableException. So we would need a
SedaConsumerNotAvailableException for this component.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6258) Sql component - Add noop option to execute the query but dont change the message body afterwards
[ https://issues.apache.org/jira/browse/CAMEL-6258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740393#comment-13740393 ] Christian Posta commented on CAMEL-6258: Very nice. I will take a look at adding this. Sql component - Add noop option to execute the query but dont change the message body afterwards Key: CAMEL-6258 URL: https://issues.apache.org/jira/browse/CAMEL-6258 Project: Camel Issue Type: Improvement Components: camel-sql Affects Versions: 2.10.0 Reporter: Claus Ibsen Priority: Minor Fix For: 2.12.0 See http://blog.mgm-tp.com/2013/04/camel-router-part1/comment-page-1/#comment-4161 Even if the query returns a result set, you may not want to grab that or change the message body. For that we can have a noop=true|false option. If there is a better name for the option then we can go for that, though noop was the first name that came to my mind. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6435) Remove obsolete 'transient' modifier from static fields
[ https://issues.apache.org/jira/browse/CAMEL-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13740442#comment-13740442 ] Matthew Aynalem commented on CAMEL-6435: Claus, here you go https://github.com/apache/camel/pull/40 Remove obsolete 'transient' modifier from static fields --- Key: CAMEL-6435 URL: https://issues.apache.org/jira/browse/CAMEL-6435 Project: Camel Issue Type: Improvement Affects Versions: 2.11.0 Reporter: Henryk Konsek Priority: Minor Fix For: 3.0.0, Future In many places within the Camel code base we can find static fields with transient modifier. Static fields are automatically transient, so the latter declaration is obsolete. We should clean the code base from the obsolete transient keywords. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
