[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184908#comment-14184908
]
Charles Moulliard commented on CAMEL-7925:
--
- Version of camel used : 2.12
- The version of Karaf does not affect this issue which is a classloading
problem
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7965) EndpointCache - Should keep endpoints from routes in the cache
Claus Ibsen created CAMEL-7965: -- Summary: EndpointCache - Should keep endpoints from routes in the cache Key: CAMEL-7965 URL: https://issues.apache.org/jira/browse/CAMEL-7965 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Claus Ibsen Priority: Minor Fix For: Future See http://camel.465427.n5.nabble.com/camelContext-hasEndpoint-returns-null-when-endpoint-apparently-exists-tp5757907.html The endpoint cache is a LRU based. But endpoints created from the routes may not be looked up in the cache for a while, and could potential be evicted from the cache. We should keep those endpoints from the routes in the cache at all times. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7964) camel-jetty should support Post Redirect Get WebDesign pattern
[ https://issues.apache.org/jira/browse/CAMEL-7964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7964. - Resolution: Fixed Applied patch into camel master branch. camel-jetty should support Post Redirect Get WebDesign pattern -- Key: CAMEL-7964 URL: https://issues.apache.org/jira/browse/CAMEL-7964 Project: Camel Issue Type: Bug Components: camel-jetty Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.15.0 The HTTP 303 response in response to a POST indicates that the POST was successful. Currently, Camel Jetty will throw an exception by default for a 303. There is a work around for this, but it involves setting throwExceptionOnFailure=true, which then ignores legitimate errors. For reference on how 303 responses should work, please see the following: http://en.wikipedia.org/wiki/Post/Redirect/Get For camel-jetty, we can add CamelRedirectListener to do this kind of thing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7919) Add tests for camel-jira component
[ https://issues.apache.org/jira/browse/CAMEL-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7919. - Resolution: Fixed Fix Version/s: 2.15.0 Applied patch into master branch with thanks to Kevin. Add tests for camel-jira component -- Key: CAMEL-7919 URL: https://issues.apache.org/jira/browse/CAMEL-7919 Project: Camel Issue Type: Bug Reporter: Kevin Earls Assignee: Willem Jiang Priority: Minor Fix For: 2.15.0 The new camel-jira component needs tests -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7792) JIRA component
[ https://issues.apache.org/jira/browse/CAMEL-7792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7792. - Resolution: Fixed JIRA component -- Key: CAMEL-7792 URL: https://issues.apache.org/jira/browse/CAMEL-7792 Project: Camel Issue Type: New Feature Reporter: Brett E. Meyer Assignee: Willem Jiang Fix For: 2.15.0 For Overlord (http://projectoverlord.io), we need to consume events from JIRA, as well as produce actions. We're moving towards using Camel as a backbone for various capabilities, and as such are writing the endpoint functionality as new Camel components. I'd love to see this incorporated as another mainline Camel component. Work in progress: https://github.com/brmeyer/camel-jira Consumer ideas: jira://newIssue (new tickets) jira://newComment (new comments on tickets) Producer ideas: jira://newComment (add comment to a ticket) Obviously, that's only a small portion of the capabilities. The JIRA API is extensive and opens a large variety of possibilities. It uses the Atlassian's jira-rest-java-client SDK (https://marketplace.atlassian.com/plugins/com.atlassian.jira.jira-rest-java-client), released under an Apache V2 license. Similar to what I did for camel-twitter, the Exchange payloads would be the SDK-provided objects themselves (Issue, Comment, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7967) camel-rabbitmq logging exceptions as debug
Marco Crivellaro created CAMEL-7967: --- Summary: camel-rabbitmq logging exceptions as debug Key: CAMEL-7967 URL: https://issues.apache.org/jira/browse/CAMEL-7967 Project: Camel Issue Type: Bug Components: camel-rabbitmq Affects Versions: 2.14.0 Reporter: Marco Crivellaro Connecting to RabbitMQ using camel-rabbitmq I've noticed that no ERROR is logged if the component cannot connect, the exceptions are handled and logged as DEBUG. This is a bit inconvenient as logging all DEBUG messages for the component fills up our logs, in production we usually set INFO as threshold. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7935) JcloudsPayloadConverter.toPayload(InputStream) cannot deal with FileInputStreamCache
[ https://issues.apache.org/jira/browse/CAMEL-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7935. - Resolution: Fixed Applied patch into camel master, camel-2.14.x and camel-2.13.x branches. JcloudsPayloadConverter.toPayload(InputStream) cannot deal with FileInputStreamCache Key: CAMEL-7935 URL: https://issues.apache.org/jira/browse/CAMEL-7935 Project: Camel Issue Type: Bug Components: camel-jclouds Affects Versions: 2.13.2, 2.14.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 StackOverflowError if body is FileInputStreamCache. http://camel.465427.n5.nabble.com/camel-jclouds-StackOverflowError-if-body-is-FileInputStreamCache-tp5757810.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7966) Doesn't set the blank or empty string the mail recipients
Willem Jiang created CAMEL-7966:
---
Summary: Doesn't set the blank or empty string the mail recipients
Key: CAMEL-7966
URL: https://issues.apache.org/jira/browse/CAMEL-7966
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.14.0, 2.13.2
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.13.3, 2.14.1, 2.15.0
Here is [the user
complain|http://camel.465427.n5.nabble.com/Camel-Mail-CC-and-BCC-headers-tp5757943p5757950.html]
in the mailing list.
{code}
I recently had a production issue where there was an exception thrown when
the CC or the BCC headers were set to :
com.sun.mail.smtp.SMTPAddressFailedException: 554 5.1.1 Invalid recipient
address
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7966) Doesn't set the blank or empty string to the mail recipients
[
https://issues.apache.org/jira/browse/CAMEL-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CAMEL-7966:
Summary: Doesn't set the blank or empty string to the mail recipients
(was: Doesn't set the blank or empty string the mail recipients)
Doesn't set the blank or empty string to the mail recipients
Key: CAMEL-7966
URL: https://issues.apache.org/jira/browse/CAMEL-7966
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.13.2, 2.14.0
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.13.3, 2.14.1, 2.15.0
Here is [the user
complain|http://camel.465427.n5.nabble.com/Camel-Mail-CC-and-BCC-headers-tp5757943p5757950.html]
in the mailing list.
{code}
I recently had a production issue where there was an exception thrown when
the CC or the BCC headers were set to :
com.sun.mail.smtp.SMTPAddressFailedException: 554 5.1.1 Invalid recipient
address
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7966) Doesn't set the blank or empty string to the mail recipients
[
https://issues.apache.org/jira/browse/CAMEL-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7966.
-
Resolution: Fixed
Doesn't set the blank or empty string to the mail recipients
Key: CAMEL-7966
URL: https://issues.apache.org/jira/browse/CAMEL-7966
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.13.2, 2.14.0
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.13.3, 2.14.1, 2.15.0
Here is [the user
complain|http://camel.465427.n5.nabble.com/Camel-Mail-CC-and-BCC-headers-tp5757943p5757950.html]
in the mailing list.
{code}
I recently had a production issue where there was an exception thrown when
the CC or the BCC headers were set to :
com.sun.mail.smtp.SMTPAddressFailedException: 554 5.1.1 Invalid recipient
address
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7966) Doesn't set the blank or empty string to the mail recipients
[
https://issues.apache.org/jira/browse/CAMEL-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184979#comment-14184979
]
Willem Jiang commented on CAMEL-7966:
-
Applied the patch into camel master, camel-2.14.x and camel-2.13.x.
Doesn't set the blank or empty string to the mail recipients
Key: CAMEL-7966
URL: https://issues.apache.org/jira/browse/CAMEL-7966
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.13.2, 2.14.0
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.13.3, 2.14.1, 2.15.0
Here is [the user
complain|http://camel.465427.n5.nabble.com/Camel-Mail-CC-and-BCC-headers-tp5757943p5757950.html]
in the mailing list.
{code}
I recently had a production issue where there was an exception thrown when
the CC or the BCC headers were set to :
com.sun.mail.smtp.SMTPAddressFailedException: 554 5.1.1 Invalid recipient
address
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
[ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185021#comment-14185021 ] Yves De Moor commented on CAMEL-5539: - I would suggest two changes in the current implementation : 1. Ability to call a route when the the circuit is open and not only when it is closed (to allow for instance to go further with a degraded mode, or to return a functional error, ...). The source code currently add a RejectedExecutionException to the exchange. I don't know if this is a camel expected behaviour as it is usually thrown to reject the execution when camel is shutting down. 2. If change 1 is accepted, we could set the number of failure in the exchange so we could for instance react the first time the circuit is open (write to the log, send an alert, or whatever else) What are your opinion ? Circuit Breaker EIP --- Key: CAMEL-5539 URL: https://issues.apache.org/jira/browse/CAMEL-5539 Project: Camel Issue Type: New Feature Components: camel-core, eip Reporter: Claus Ibsen Assignee: Raúl Kripalani Fix For: Future Attachments: CAMEL-5539-output-82ef800.txt, CAMEL-5539-output.txt Look at add the circuit breaker EIP to the Camel DSL. http://davybrion.com/blog/2008/05/the-circuit-breaker/ Would need some thoughts for that though. Either as an explicit in the DSL. Or as a interceptor for sending to an endpoint. As explicit its a kind to the load balancer (in fact it may be extended upon that). Either the LB selects the intended target, or it select the breaker, which rejects executing the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7968) Container has undefined concurrency behaviour
Thomas Diesler created CAMEL-7968: - Summary: Container has undefined concurrency behaviour Key: CAMEL-7968 URL: https://issues.apache.org/jira/browse/CAMEL-7968 Project: Camel Issue Type: Bug Affects Versions: 2.14.0 Reporter: Thomas Diesler The implementation of Container.Instance is not ThreadSafe. It is also not defined what happens when multiple Containers race on the singleton. Instead of using a Container singleton approach. It might be better to have a singleton ContainerRegistry that can handle concurrent/multiple Containers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
[ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185065#comment-14185065 ] Bilgin Ibryam commented on CAMEL-5539: -- Sounds like a good improvements to add. Feel free to create issues and do PRs Circuit Breaker EIP --- Key: CAMEL-5539 URL: https://issues.apache.org/jira/browse/CAMEL-5539 Project: Camel Issue Type: New Feature Components: camel-core, eip Reporter: Claus Ibsen Assignee: Raúl Kripalani Fix For: Future Attachments: CAMEL-5539-output-82ef800.txt, CAMEL-5539-output.txt Look at add the circuit breaker EIP to the Camel DSL. http://davybrion.com/blog/2008/05/the-circuit-breaker/ Would need some thoughts for that though. Either as an explicit in the DSL. Or as a interceptor for sending to an endpoint. As explicit its a kind to the load balancer (in fact it may be extended upon that). Either the LB selects the intended target, or it select the breaker, which rejects executing the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7969) Container only sees Context with default name
Thomas Diesler created CAMEL-7969:
-
Summary: Container only sees Context with default name
Key: CAMEL-7969
URL: https://issues.apache.org/jira/browse/CAMEL-7969
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.0
Reporter: Thomas Diesler
In the case of SpringCamelContext we have this code
{code}
protected SpringCamelContext createContext() {
SpringCamelContext ctx = newCamelContext();
ctx.setName(getId());
return ctx;
}
{code}
The Container singleton is however called from the DefaultCamelContext ctor
(i.e. before the name is initialised properly)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7969) Container sees Context prematurely (with default name)
[
https://issues.apache.org/jira/browse/CAMEL-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Diesler updated CAMEL-7969:
--
Summary: Container sees Context prematurely (with default name) (was:
Container only sees Context with default name)
Container sees Context prematurely (with default name)
--
Key: CAMEL-7969
URL: https://issues.apache.org/jira/browse/CAMEL-7969
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.0
Reporter: Thomas Diesler
In the case of SpringCamelContext we have this code
{code}
protected SpringCamelContext createContext() {
SpringCamelContext ctx = newCamelContext();
ctx.setName(getId());
return ctx;
}
{code}
The Container singleton is however called from the DefaultCamelContext ctor
(i.e. before the name is initialised properly)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7970) Container does not see the unregister event
Thomas Diesler created CAMEL-7970: - Summary: Container does not see the unregister event Key: CAMEL-7970 URL: https://issues.apache.org/jira/browse/CAMEL-7970 Project: Camel Issue Type: Bug Affects Versions: 2.14.0 Reporter: Thomas Diesler Clients of the Container SPI see contexts being added but not removed. In wildfly we expose every context as an msc service to allow for service dependencies on it. When a context gets unregistered we must also unregister the msc service. unmanage(CamelContext) should probably be exposed in the same way as manage(CamelContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7967) camel-rabbitmq logging exceptions as debug
[ https://issues.apache.org/jira/browse/CAMEL-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-7967: --- Assignee: Willem Jiang camel-rabbitmq logging exceptions as debug -- Key: CAMEL-7967 URL: https://issues.apache.org/jira/browse/CAMEL-7967 Project: Camel Issue Type: Bug Components: camel-rabbitmq Affects Versions: 2.14.0 Reporter: Marco Crivellaro Assignee: Willem Jiang Connecting to RabbitMQ using camel-rabbitmq I've noticed that no ERROR is logged if the component cannot connect, the exceptions are handled and logged as DEBUG. This is a bit inconvenient as logging all DEBUG messages for the component fills up our logs, in production we usually set INFO as threshold. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7969) Container sees Context prematurely (with default name)
[
https://issues.apache.org/jira/browse/CAMEL-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185086#comment-14185086
]
Thomas Diesler commented on CAMEL-7969:
---
It is generally wrong to call an SPI extension point from a constructor when
the class is not final. For example, a SpringCamelContext would not be fully
initialised/constructed when the call to Container.manage(CamelContext) happens.
Container sees Context prematurely (with default name)
--
Key: CAMEL-7969
URL: https://issues.apache.org/jira/browse/CAMEL-7969
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.0
Reporter: Thomas Diesler
In the case of SpringCamelContext we have this code
{code}
protected SpringCamelContext createContext() {
SpringCamelContext ctx = newCamelContext();
ctx.setName(getId());
return ctx;
}
{code}
The Container singleton is however called from the DefaultCamelContext ctor
(i.e. before the name is initialised properly)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7971) Setting bean reference in restConfiguration fails with IllegalFormatWidthException
Ralf Steppacher created CAMEL-7971:
--
Summary: Setting bean reference in restConfiguration fails with
IllegalFormatWidthException
Key: CAMEL-7971
URL: https://issues.apache.org/jira/browse/CAMEL-7971
Project: Camel
Issue Type: Bug
Components: camel-core, camel-netty4-http
Affects Versions: 2.14.0
Reporter: Ralf Steppacher
I am trying to set a custom HTTP binding on the netty4-http endpoint created
for the REST-DSL routes. The '#' in the bean ref, URL encoded as %23, makes the
endpoint generation fail because it is interpreted by the string formatter.
{code:xml}
restConfiguration component=netty4-http scheme=http host={{rest.host}}
port={{rest.port}} bindingMode=json
endpointProperty key=nettyHttpBinding
value=#noStackTraceHTTPBinding/
/restConfiguration
rest path=/base produces=application/json
get uri=/path
to uri=direct:myroute /
/get
/rest
{code}
This configuration results in the following template string
(NettyHttpComponent.java line 279):
{{netty4-http:%s://%s:%s/%s?httpMethodRestrict=%s?nettyHttpBinding=%23noStackTraceHTTPBinding}}
The main problem is the hash mark encoded as %23 and interpreted by the
string formatter. Also, the second '?' in the URL probably should be a ''.
Full stacktrace:
{code}
java.util.IllegalFormatWidthException: 23
at
java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2996)[:1.7.0_60]
at
java.util.Formatter$FormatSpecifier.init(Formatter.java:2688)[:1.7.0_60]
at java.util.Formatter.parse(Formatter.java:2528)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2469)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2423)[:1.7.0_60]
at java.lang.String.format(String.java:2790)[:1.7.0_60]
at
org.apache.camel.component.netty4.http.NettyHttpComponent.createConsumer(NettyHttpComponent.java:279)
at
org.apache.camel.component.rest.RestEndpoint.createConsumer(RestEndpoint.java:167)
at
org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65)
at
org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:80)
at org.apache.camel.impl.RouteService.warmUp(RouteService.java:134)
at
org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:2379)
at
org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:2309)
at
org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:2091)
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1951)
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1777)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1745)
at
org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:177)
at
org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:209)
at
org.apache.camel.blueprint.BlueprintCamelContext.serviceChanged(BlueprintCamelContext.java:147)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)
at org.apache.felix.framework.Felix.registerService(Felix.java:3423)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:387)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
at
[jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
[ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185200#comment-14185200 ] Yves De Moor commented on CAMEL-5539: - Simple, quick and most flexible solution could be : Put the number of failure in an exchange property. Put circuit state in an exchange property (2 status : Open / closed, as halfOpen do the same as closed in term of business) use a Content Based Router to perform something like from(direct:a) .loadBalance()// .circuitBreaker(3, 3000L, MyCustomException.class) .choice() .when(property(Exchange.CircuitBreaker_state).isEqualTo(closed)) .to(direct:normalMode) .when(property(Exchange.CircuitBreaker_state).isEqualTo(opened)) .to(direct:degradedMode) .end() from(direct:degradedMode) .choice() .when(property(Exchange.CircuitBreaker_errorCount).isEqualTo(1)) //First error encountered, send an alert to monitoring .to(direct:monitorging_alert_degradedMode) .end() I also see the current solution is not enough robust. when halfOpen is reached, (System.currentTimeMillis() - lastFailure halfOpenAfter) there is no restriction on the number of calls (threads) that will perform a retry. When retry timeout is reached, we should let only 1 thread go in halfOpen mode, all other should be kept in open state until an halfOpen succeed. (will create new issue for this) Yves. Circuit Breaker EIP --- Key: CAMEL-5539 URL: https://issues.apache.org/jira/browse/CAMEL-5539 Project: Camel Issue Type: New Feature Components: camel-core, eip Reporter: Claus Ibsen Assignee: Raúl Kripalani Fix For: Future Attachments: CAMEL-5539-output-82ef800.txt, CAMEL-5539-output.txt Look at add the circuit breaker EIP to the Camel DSL. http://davybrion.com/blog/2008/05/the-circuit-breaker/ Would need some thoughts for that though. Either as an explicit in the DSL. Or as a interceptor for sending to an endpoint. As explicit its a kind to the load balancer (in fact it may be extended upon that). Either the LB selects the intended target, or it select the breaker, which rejects executing the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7969) Container sees Context prematurely (with default name)
[
https://issues.apache.org/jira/browse/CAMEL-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Diesler updated CAMEL-7969:
--
Description:
In the case of SpringCamelContext we have this code
{code}
protected SpringCamelContext createContext() {
SpringCamelContext ctx = newCamelContext();
ctx.setName(getId());
return ctx;
}
{code}
The Container singleton is however called from the DefaultCamelContext ctor
(i.e. before the name is initialised properly)
CrossRef: https://github.com/tdiesler/wildfly-camel/issues/16
was:
In the case of SpringCamelContext we have this code
{code}
protected SpringCamelContext createContext() {
SpringCamelContext ctx = newCamelContext();
ctx.setName(getId());
return ctx;
}
{code}
The Container singleton is however called from the DefaultCamelContext ctor
(i.e. before the name is initialised properly)
Container sees Context prematurely (with default name)
--
Key: CAMEL-7969
URL: https://issues.apache.org/jira/browse/CAMEL-7969
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.0
Reporter: Thomas Diesler
In the case of SpringCamelContext we have this code
{code}
protected SpringCamelContext createContext() {
SpringCamelContext ctx = newCamelContext();
ctx.setName(getId());
return ctx;
}
{code}
The Container singleton is however called from the DefaultCamelContext ctor
(i.e. before the name is initialised properly)
CrossRef: https://github.com/tdiesler/wildfly-camel/issues/16
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7972) Make the Circuit Breaker EIP more robust - in state halfOpen let only one thread to perform a try
Yves De Moor created CAMEL-7972: --- Summary: Make the Circuit Breaker EIP more robust - in state halfOpen let only one thread to perform a try Key: CAMEL-7972 URL: https://issues.apache.org/jira/browse/CAMEL-7972 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Yves De Moor when halfOpen is reached, (System.currentTimeMillis() - lastFailure halfOpenAfter) there is no restriction on the number of calls (threads) that will perform a retry. When retry timeout is reached, we should let only 1 thread go in halfOpen mode, all other should be kept in open state until an halfOpen succeed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7973) CircuitBreakerLoadBalancer fails on async processors
Matteo Pavesi created CAMEL-7973: Summary: CircuitBreakerLoadBalancer fails on async processors Key: CAMEL-7973 URL: https://issues.apache.org/jira/browse/CAMEL-7973 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0 Reporter: Matteo Pavesi Priority: Minor The CircuitBreakerLoadBalancer works fine on direct synchronous processor, but it seems to not behave as expected in case of async processor. To reproduce the error, it's enough to add a .threads(1) before the mock processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. This misbehaviour seems to be related to the use of the AsyncProcessorConverterHelper to force any processor to behave like asynchronous. I'm going to submit a pull request with the failing test and a proposal of solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7974) Provide CircuitBreaker state in an exchange property
Yves De Moor created CAMEL-7974: --- Summary: Provide CircuitBreaker state in an exchange property Key: CAMEL-7974 URL: https://issues.apache.org/jira/browse/CAMEL-7974 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Yves De Moor To be more flexible, the idea is to create some exchange properties Put circuit state in an exchange property (2 status : Open / closed, as halfOpen do the same as closed in term of business) use a Content Based Router to perform something like from(direct:a) .loadBalance()// .circuitBreaker(3, 3000L, MyCustomException.class) .choice() .when(property(Exchange.CircuitBreaker_state).isEqualTo(closed)) .to(direct:normalMode) .when(property(Exchange.CircuitBreaker_state).isEqualTo(opened)) .to(direct:degradedMode) .end() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7973) CircuitBreakerLoadBalancer fails on async processors
[ https://issues.apache.org/jira/browse/CAMEL-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Pavesi updated CAMEL-7973: - Description: The CircuitBreakerLoadBalancer works fine on direct synchronous processor, but it seems to not behave as expected in case of async processor. To reproduce the error, it's enough to add a .threads(1) before the mock processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. This misbehaviour seems to be related to the use of the AsyncProcessorConverterHelper to force any processor to behave like asynchronous. I'm going to propose a patch with the failing test and a proposal of solution. was: The CircuitBreakerLoadBalancer works fine on direct synchronous processor, but it seems to not behave as expected in case of async processor. To reproduce the error, it's enough to add a .threads(1) before the mock processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. This misbehaviour seems to be related to the use of the AsyncProcessorConverterHelper to force any processor to behave like asynchronous. I'm going to submit a pull request with the failing test and a proposal of solution. CircuitBreakerLoadBalancer fails on async processors Key: CAMEL-7973 URL: https://issues.apache.org/jira/browse/CAMEL-7973 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0 Reporter: Matteo Pavesi Priority: Minor The CircuitBreakerLoadBalancer works fine on direct synchronous processor, but it seems to not behave as expected in case of async processor. To reproduce the error, it's enough to add a .threads(1) before the mock processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. This misbehaviour seems to be related to the use of the AsyncProcessorConverterHelper to force any processor to behave like asynchronous. I'm going to propose a patch with the failing test and a proposal of solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7973) CircuitBreakerLoadBalancer fails on async processors
[ https://issues.apache.org/jira/browse/CAMEL-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Pavesi updated CAMEL-7973: - Attachment: 0002-CAMEL-7973-fix-circuit-breaker-with-async-processors.patch 0001-CAMEL-7973-added-failing-test-for-circuit-breaker-wi.patch Patches (based on branch 2.14.x) containing failing test and proposed solution. CircuitBreakerLoadBalancer fails on async processors Key: CAMEL-7973 URL: https://issues.apache.org/jira/browse/CAMEL-7973 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0 Reporter: Matteo Pavesi Priority: Minor Attachments: 0001-CAMEL-7973-added-failing-test-for-circuit-breaker-wi.patch, 0002-CAMEL-7973-fix-circuit-breaker-with-async-processors.patch The CircuitBreakerLoadBalancer works fine on direct synchronous processor, but it seems to not behave as expected in case of async processor. To reproduce the error, it's enough to add a .threads(1) before the mock processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. This misbehaviour seems to be related to the use of the AsyncProcessorConverterHelper to force any processor to behave like asynchronous. I'm going to propose a patch with the failing test and a proposal of solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7973) CircuitBreakerLoadBalancer fails on async processors
[ https://issues.apache.org/jira/browse/CAMEL-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185291#comment-14185291 ] Matteo Pavesi edited comment on CAMEL-7973 at 10/27/14 4:10 PM: Added patches (based on branch 2.14.x) containing failing test and proposed solution. was (Author: matteo pavesi): Patches (based on branch 2.14.x) containing failing test and proposed solution. CircuitBreakerLoadBalancer fails on async processors Key: CAMEL-7973 URL: https://issues.apache.org/jira/browse/CAMEL-7973 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0 Reporter: Matteo Pavesi Priority: Minor Attachments: 0001-CAMEL-7973-added-failing-test-for-circuit-breaker-wi.patch, 0002-CAMEL-7973-fix-circuit-breaker-with-async-processors.patch The CircuitBreakerLoadBalancer works fine on direct synchronous processor, but it seems to not behave as expected in case of async processor. To reproduce the error, it's enough to add a .threads(1) before the mock processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. This misbehaviour seems to be related to the use of the AsyncProcessorConverterHelper to force any processor to behave like asynchronous. I'm going to propose a patch with the failing test and a proposal of solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7975) SJMS Endpoint does not reverse header encoding
Aaron Whiteside created CAMEL-7975:
--
Summary: SJMS Endpoint does not reverse header encoding
Key: CAMEL-7975
URL: https://issues.apache.org/jira/browse/CAMEL-7975
Project: Camel
Issue Type: Bug
Components: camel-sjms
Affects Versions: 2.14.0
Reporter: Aaron Whiteside
Priority: Minor
SJMS Endpoint does not reverse header encoding, when it replaces . with \_DOT\_
and - with \_HYPHEN\_ it does not replace them with the original values.
So this breaks compatibility with the camel-jms component.
Quote taken from: http://camel.apache.org/jms.html
{quote}
The current header name strategy for accepting header names in Camel is as
follows:
Dots are replaced by \_DOT\_ and the replacement is reversed when Camel consume
the message
Hyphen is replaced by \_HYPHEN\_ and the replacement is reversed when Camel
consumes the message
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7975) SJMS Endpoint does not reverse header encoding
[
https://issues.apache.org/jira/browse/CAMEL-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Whiteside updated CAMEL-7975:
---
Attachment: unnamed3.patch
Patch attached
SJMS Endpoint does not reverse header encoding
--
Key: CAMEL-7975
URL: https://issues.apache.org/jira/browse/CAMEL-7975
Project: Camel
Issue Type: Bug
Components: camel-sjms
Affects Versions: 2.14.0
Reporter: Aaron Whiteside
Priority: Minor
Attachments: unnamed3.patch
SJMS Endpoint does not reverse header encoding, when it replaces . with
\_DOT\_ and - with \_HYPHEN\_ it does not replace them with the original
values.
So this breaks compatibility with the camel-jms component.
Quote taken from: http://camel.apache.org/jms.html
{quote}
The current header name strategy for accepting header names in Camel is as
follows:
Dots are replaced by \_DOT\_ and the replacement is reversed when Camel
consume the message
Hyphen is replaced by \_HYPHEN\_ and the replacement is reversed when Camel
consumes the message
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7963) Add Spring Boot support
[ https://issues.apache.org/jira/browse/CAMEL-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henryk Konsek resolved CAMEL-7963. -- Resolution: Fixed Done. I'm gonna improve some docs bits, add tests helpers API, but usable base is ready. Add Spring Boot support --- Key: CAMEL-7963 URL: https://issues.apache.org/jira/browse/CAMEL-7963 Project: Camel Issue Type: New Feature Reporter: Henryk Konsek Assignee: Henryk Konsek Fix For: 2.15.0 We need Spring Boot autoconfiguration for Camel. I created one under Fabric8 umbrella (1), but I don't believe that is the proper place to keep and develop Camel integration, as this is pure Camel stuff. We can just use Camel stuff in the Fabric8 instead. I will continue to develop Camel Spring Boot integration under Camel umbrella. (1) https://github.com/fabric8io/fabric8/tree/master/process/process-spring-boot/process-spring-boot-starter-camel -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7927) Add support for Multi-Select picklists in Salesforce component
[ https://issues.apache.org/jira/browse/CAMEL-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7927: Affects Version/s: 2.13.2 Add support for Multi-Select picklists in Salesforce component -- Key: CAMEL-7927 URL: https://issues.apache.org/jira/browse/CAMEL-7927 Project: Camel Issue Type: Improvement Components: camel-salesforce Affects Versions: 2.13.2, 2.14.0 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Labels: camel, camel-salesforce, salesforce Salesforce represents multi-select picklists values as a ';' separated list of enumerated values. Handling this would require an XStream converter for XML, and a Jackson serializer and deserializer for JSON, to map from this string format to a list of picklist enumeration values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7927) Add support for Multi-Select picklists in Salesforce component
[ https://issues.apache.org/jira/browse/CAMEL-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7927: Fix Version/s: 2.13.3 Add support for Multi-Select picklists in Salesforce component -- Key: CAMEL-7927 URL: https://issues.apache.org/jira/browse/CAMEL-7927 Project: Camel Issue Type: Improvement Components: camel-salesforce Affects Versions: 2.13.2, 2.14.0 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Labels: camel, camel-salesforce, salesforce Salesforce represents multi-select picklists values as a ';' separated list of enumerated values. Handling this would require an XStream converter for XML, and a Jackson serializer and deserializer for JSON, to map from this string format to a list of picklist enumeration values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7927) Add support for Multi-Select picklists in Salesforce component
[ https://issues.apache.org/jira/browse/CAMEL-7927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7927: Fix Version/s: (was: 2.14.1) (was: 2.15.0) (was: 2.13.3) Add support for Multi-Select picklists in Salesforce component -- Key: CAMEL-7927 URL: https://issues.apache.org/jira/browse/CAMEL-7927 Project: Camel Issue Type: Improvement Components: camel-salesforce Affects Versions: 2.13.2, 2.14.0 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Labels: camel, camel-salesforce, salesforce Salesforce represents multi-select picklists values as a ';' separated list of enumerated values. Handling this would require an XStream converter for XML, and a Jackson serializer and deserializer for JSON, to map from this string format to a list of picklist enumeration values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7971) Setting bean reference in restConfiguration fails with IllegalFormatWidthException
[
https://issues.apache.org/jira/browse/CAMEL-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang reassigned CAMEL-7971:
---
Assignee: Willem Jiang
Setting bean reference in restConfiguration fails with
IllegalFormatWidthException
Key: CAMEL-7971
URL: https://issues.apache.org/jira/browse/CAMEL-7971
Project: Camel
Issue Type: Bug
Components: camel-core, camel-netty4-http
Affects Versions: 2.14.0
Reporter: Ralf Steppacher
Assignee: Willem Jiang
I am trying to set a custom HTTP binding on the netty4-http endpoint created
for the REST-DSL routes. The '#' in the bean ref, URL encoded as %23, makes
the endpoint generation fail because it is interpreted by the string
formatter.
{code:xml}
restConfiguration component=netty4-http scheme=http host={{rest.host}}
port={{rest.port}} bindingMode=json
endpointProperty key=nettyHttpBinding
value=#noStackTraceHTTPBinding/
/restConfiguration
rest path=/base produces=application/json
get uri=/path
to uri=direct:myroute /
/get
/rest
{code}
This configuration results in the following template string
(NettyHttpComponent.java line 279):
{{netty4-http:%s://%s:%s/%s?httpMethodRestrict=%s?nettyHttpBinding=%23noStackTraceHTTPBinding}}
The main problem is the hash mark encoded as %23 and interpreted by the
string formatter. Also, the second '?' in the URL probably should be a ''.
Full stacktrace:
{code}
java.util.IllegalFormatWidthException: 23
at
java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2996)[:1.7.0_60]
at
java.util.Formatter$FormatSpecifier.init(Formatter.java:2688)[:1.7.0_60]
at java.util.Formatter.parse(Formatter.java:2528)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2469)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2423)[:1.7.0_60]
at java.lang.String.format(String.java:2790)[:1.7.0_60]
at
org.apache.camel.component.netty4.http.NettyHttpComponent.createConsumer(NettyHttpComponent.java:279)
at
org.apache.camel.component.rest.RestEndpoint.createConsumer(RestEndpoint.java:167)
at
org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65)
at
org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:80)
at org.apache.camel.impl.RouteService.warmUp(RouteService.java:134)
at
org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:2379)
at
org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:2309)
at
org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:2091)
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1951)
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1777)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1745)
at
org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:177)
at
org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:209)
at
org.apache.camel.blueprint.BlueprintCamelContext.serviceChanged(BlueprintCamelContext.java:147)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)
at org.apache.felix.framework.Felix.registerService(Felix.java:3423)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:387)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)
at
org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:235)
at
[jira] [Resolved] (CAMEL-7971) Setting bean reference in restConfiguration fails with IllegalFormatWidthException
[
https://issues.apache.org/jira/browse/CAMEL-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7971.
-
Resolution: Fixed
Fix Version/s: 2.15.0
2.14.1
Applied the patch into camel master, camel-2.14.x branches.
Setting bean reference in restConfiguration fails with
IllegalFormatWidthException
Key: CAMEL-7971
URL: https://issues.apache.org/jira/browse/CAMEL-7971
Project: Camel
Issue Type: Bug
Components: camel-core, camel-netty4-http
Affects Versions: 2.14.0
Reporter: Ralf Steppacher
Assignee: Willem Jiang
Fix For: 2.14.1, 2.15.0
I am trying to set a custom HTTP binding on the netty4-http endpoint created
for the REST-DSL routes. The '#' in the bean ref, URL encoded as %23, makes
the endpoint generation fail because it is interpreted by the string
formatter.
{code:xml}
restConfiguration component=netty4-http scheme=http host={{rest.host}}
port={{rest.port}} bindingMode=json
endpointProperty key=nettyHttpBinding
value=#noStackTraceHTTPBinding/
/restConfiguration
rest path=/base produces=application/json
get uri=/path
to uri=direct:myroute /
/get
/rest
{code}
This configuration results in the following template string
(NettyHttpComponent.java line 279):
{{netty4-http:%s://%s:%s/%s?httpMethodRestrict=%s?nettyHttpBinding=%23noStackTraceHTTPBinding}}
The main problem is the hash mark encoded as %23 and interpreted by the
string formatter. Also, the second '?' in the URL probably should be a ''.
Full stacktrace:
{code}
java.util.IllegalFormatWidthException: 23
at
java.util.Formatter$FormatSpecifier.checkText(Formatter.java:2996)[:1.7.0_60]
at
java.util.Formatter$FormatSpecifier.init(Formatter.java:2688)[:1.7.0_60]
at java.util.Formatter.parse(Formatter.java:2528)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2469)[:1.7.0_60]
at java.util.Formatter.format(Formatter.java:2423)[:1.7.0_60]
at java.lang.String.format(String.java:2790)[:1.7.0_60]
at
org.apache.camel.component.netty4.http.NettyHttpComponent.createConsumer(NettyHttpComponent.java:279)
at
org.apache.camel.component.rest.RestEndpoint.createConsumer(RestEndpoint.java:167)
at
org.apache.camel.impl.EventDrivenConsumerRoute.addServices(EventDrivenConsumerRoute.java:65)
at
org.apache.camel.impl.DefaultRoute.onStartingServices(DefaultRoute.java:80)
at org.apache.camel.impl.RouteService.warmUp(RouteService.java:134)
at
org.apache.camel.impl.DefaultCamelContext.doWarmUpRoutes(DefaultCamelContext.java:2379)
at
org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:2309)
at
org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:2091)
at
org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1951)
at
org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1777)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at
org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1745)
at
org.apache.camel.blueprint.BlueprintCamelContext.start(BlueprintCamelContext.java:177)
at
org.apache.camel.blueprint.BlueprintCamelContext.maybeStart(BlueprintCamelContext.java:209)
at
org.apache.camel.blueprint.BlueprintCamelContext.serviceChanged(BlueprintCamelContext.java:147)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4419)
at org.apache.felix.framework.Felix.registerService(Felix.java:3423)
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:346)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.registerService(BlueprintContainerImpl.java:452)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:387)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:269)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:276)
at
org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:245)
at
[jira] [Created] (CAMEL-7976) Validation of feature camel-ssh is failing
Christian Müller created CAMEL-7976:
---
Summary: Validation of feature camel-ssh is failing
Key: CAMEL-7976
URL: https://issues.apache.org/jira/browse/CAMEL-7976
Project: Camel
Issue Type: Task
Components: karaf
Affects Versions: 2.12.5
Reporter: Christian Müller
Assignee: Christian Müller
Fix For: 2.12.5
{noformat}
[INFO] OK: imports resolved for camel-sql
[WARNING] Failed to validate feature camel-ssh
[WARNING] No export found to match org.bouncycastle.asn1;version=1.51 (imported
by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.x500;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.util;version=1.51 (imported
by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.crypto.io;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.tsp;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match
org.bouncycastle.jcajce.provider.symmetric.util;version=1.51 (imported by
mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.dvcs;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.kisa;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.crypto.signers;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.jcajce.util;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.jcajce.io;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match
org.bouncycastle.crypto.encodings;version=1.51 (imported by
mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.crmf;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.x509;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.misc;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.x509;version=1.51 (imported
by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.iana;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.jce.spec;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.pkcs;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.jcajce.spec;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.nist;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.ess;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.crypto.util;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.x9;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.cmp;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.math.ec;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.eac;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.cms.ecc;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.crypto.macs;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.crypto.modes;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.util.io.pem;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.util.io;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.oiw;version=1.51
(imported by mvn:org.bouncycastle/bcpkix-jdk15on/1.51)
[WARNING] No export found to match org.bouncycastle.asn1.teletrust;version=1.51
