[jira] [Updated] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[ https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-9143: Affects Version/s: (was: 2.14.3) > Producers that implement the ServicePoolAware interface cause memory leak due > to JMX references > --- > > Key: CAMEL-9143 > URL: https://issues.apache.org/jira/browse/CAMEL-9143 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.1, 2.14.2, 2.15.0, 2.15.1 >Reporter: Bob Browning > > h4. Description > Producer instances that implement the ServicePoolAware interface will leak > memory if their route is stopped, with new producers being leaked every time > the route is started/stopped. > Known implementations that are affected are RemoteFileProducer (ftp, sftp) > and Mina2Producer. > This is due to the behaviour that the SendProcessor which when the route is > stopped it shuts down it's `producerCache` instance. > {code} > protected void doStop() throws Exception { > ServiceHelper.stopServices(producerCache, producer); > } > {code} > this in turn calls `stopAndShutdownService(pool)` which will call stop on the > SharedProducerServicePool instance which is a NOOP however it also calls > shutdown which effects a stop of the global pool (this stops all the > registered services and then clears the pool. > {code} > protected void doStop() throws Exception { > // when stopping we intend to shutdown > ServiceHelper.stopAndShutdownService(pool); > try { > ServiceHelper.stopAndShutdownServices(producers.values()); > } finally { > // ensure producers are removed, and also from JMX > for (Producer producer : producers.values()) { > getCamelContext().removeService(producer); > } > } > producers.clear(); > } > {code} > However no call to `context.removeService(Producer) is called for the entries > from the pool only those singleton instances that were in the `producers` map > hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes > {code}getCamelContext().addService(answer, false); > {code} is never removed. > Since the global pool is empty when the next request to get a producer is > called a new producer is created, jmx wrapper and all, whilst the old > instance remains orphaned retaining any objects that pertain to that instance. > One workaround is for the producer to call > {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop > method, however this is fairly obscure and it would probably be better to > invoke removal of the producer when it is removed from the shared pool. > Another issue of note is that when a route is shutdown that contains a > SendProcessor due to the shutdown invocation on the > SharedProcessorServicePool the global pool is cleared of `everything` and > remains in `Stopped` state until another route starts it (although it is > still accessed and used whilst in the `Stopped` state). > h4. Impact > For general use where there is no dynamic creation or passivation of routes > this issue should be minimal, however in our use case where the routes are > not static, there is a certain amount of recreation of routes as customer > endpoints change and there is a need to passivate idle routes this causes a > considerable memory leak (via SFTP in particular). > h4. Test Case > {code} > package org.apache.camel.component; > import com.google.common.util.concurrent.AtomicLongMap; > import org.apache.camel.CamelContext; > import org.apache.camel.Consumer; > import org.apache.camel.Endpoint; > import org.apache.camel.Exchange; > import org.apache.camel.Processor; > import org.apache.camel.Producer; > import org.apache.camel.Route; > import org.apache.camel.Service; > import org.apache.camel.ServicePoolAware; > import org.apache.camel.ServiceStatus; > import org.apache.camel.builder.RouteBuilder; > import org.apache.camel.impl.DefaultComponent; > import org.apache.camel.impl.DefaultEndpoint; > import org.apache.camel.impl.DefaultProducer; > import org.apache.camel.support.LifecycleStrategySupport; > import org.apache.camel.support.ServiceSupport; > import org.apache.camel.test.junit4.CamelTestSupport; > import org.junit.Test; > import java.util.Map; > import static com.google.common.base.Preconditions.checkNotNull; > /** > * Test memory behaviour of producers using {@link ServicePoolAware} when > using JMX. > */ > public class ServicePoolAwareLeakyTest extends CamelTestSupport { > private static final String LEAKY_SIEVE_STABLE = > "leaky://sieve-stable?plugged=true"; > private static final String LEAKY_SIEVE_TRANSIENT = > "leaky://sieve-transient?pl
[jira] [Updated] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
[ https://issues.apache.org/jira/browse/CAMEL-9143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Browning updated CAMEL-9143: Description: h4. Description Producer instances that implement the ServicePoolAware interface will leak memory if their route is stopped, with new producers being leaked every time the route is started/stopped. Known implementations that are affected are RemoteFileProducer (ftp, sftp) and Mina2Producer. This is due to the behaviour that the SendProcessor which when the route is stopped it shuts down it's `producerCache` instance. {code} protected void doStop() throws Exception { ServiceHelper.stopServices(producerCache, producer); } {code} this in turn calls `stopAndShutdownService(pool)` which will call stop on the SharedProducerServicePool instance which is a NOOP however it also calls shutdown which effects a stop of the global pool (this stops all the registered services and then clears the pool. {code} protected void doStop() throws Exception { // when stopping we intend to shutdown ServiceHelper.stopAndShutdownService(pool); try { ServiceHelper.stopAndShutdownServices(producers.values()); } finally { // ensure producers are removed, and also from JMX for (Producer producer : producers.values()) { getCamelContext().removeService(producer); } } producers.clear(); } {code} However no call to `context.removeService(Producer) is called for the entries from the pool only those singleton instances that were in the `producers` map hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes {code}getCamelContext().addService(answer, false); {code} is never removed. Since the global pool is empty when the next request to get a producer is called a new producer is created, jmx wrapper and all, whilst the old instance remains orphaned retaining any objects that pertain to that instance. One workaround is for the producer to call {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop method, however this is fairly obscure and it would probably be better to invoke removal of the producer when it is removed from the shared pool. Another issue of note is that when a route is shutdown that contains a SendProcessor due to the shutdown invocation on the SharedProcessorServicePool the global pool is cleared of `everything` and remains in `Stopped` state until another route starts it (although it is still accessed and used whilst in the `Stopped` state). h4. Impact For general use where there is no dynamic creation or passivation of routes this issue should be minimal, however in our use case where the routes are not static, there is a certain amount of recreation of routes as customer endpoints change and there is a need to passivate idle routes this causes a considerable memory leak (via SFTP in particular). h4. Test Case {code} package org.apache.camel.component; import com.google.common.util.concurrent.AtomicLongMap; import org.apache.camel.CamelContext; import org.apache.camel.Consumer; import org.apache.camel.Endpoint; import org.apache.camel.Exchange; import org.apache.camel.Processor; import org.apache.camel.Producer; import org.apache.camel.Route; import org.apache.camel.Service; import org.apache.camel.ServicePoolAware; import org.apache.camel.ServiceStatus; import org.apache.camel.builder.RouteBuilder; import org.apache.camel.impl.DefaultComponent; import org.apache.camel.impl.DefaultEndpoint; import org.apache.camel.impl.DefaultProducer; import org.apache.camel.support.LifecycleStrategySupport; import org.apache.camel.support.ServiceSupport; import org.apache.camel.test.junit4.CamelTestSupport; import org.junit.Test; import java.util.Map; import static com.google.common.base.Preconditions.checkNotNull; /** * Test memory behaviour of producers using {@link ServicePoolAware} when using JMX. */ public class ServicePoolAwareLeakyTest extends CamelTestSupport { private static final String LEAKY_SIEVE_STABLE = "leaky://sieve-stable?plugged=true"; private static final String LEAKY_SIEVE_TRANSIENT = "leaky://sieve-transient?plugged=true"; private static boolean isPatchApplied() { return Boolean.parseBoolean(System.getProperty("patchApplied", "false")); } /** * Component that provides leaks producers. */ private static class LeakySieveComponent extends DefaultComponent { @Override protected Endpoint createEndpoint(String uri, String remaining, Map parameters) throws Exception { boolean plugged = "true".equalsIgnoreCase((String) parameters.remove("plugged")); return new LeakySieveEndpoint(uri, isPatchApplied() && plugged); } } /** * Endpoint that provides leaky producers. */ private static class LeakySieveEndpoint extends Defau
[jira] [Created] (CAMEL-9143) Producers that implement the ServicePoolAware interface cause memory leak due to JMX references
Bob Browning created CAMEL-9143: --- Summary: Producers that implement the ServicePoolAware interface cause memory leak due to JMX references Key: CAMEL-9143 URL: https://issues.apache.org/jira/browse/CAMEL-9143 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1, 2.15.0, 2.14.3, 2.14.2, 2.14.1 Reporter: Bob Browning h4. Description Producer instances that implement the ServicePoolAware interface will leak memory if their route is stopped, with new producers being leaked every time the route is started/stopped. Known implementations that are affected are RemoteFileProducer (ftp, sftp) and Mina2Producer. This is due to the behaviour that the SendProcessor which when the route is stopped it shuts down it's `producerCache` instance. {code} protected void doStop() throws Exception { ServiceHelper.stopServices(producerCache, producer); } {code} this in turn calls `stopAndShutdownService(pool)` which will call stop on the SharedProducerServicePool instance which is a NOOP however it also calls shutdown which effects a stop of the global pool (this stops all the registered services and then clears the pool. {code} protected void doStop() throws Exception { // when stopping we intend to shutdown ServiceHelper.stopAndShutdownService(pool); try { ServiceHelper.stopAndShutdownServices(producers.values()); } finally { // ensure producers are removed, and also from JMX for (Producer producer : producers.values()) { getCamelContext().removeService(producer); } } producers.clear(); } {code} However no call to `context.removeService(Producer) is called for the entries from the pool only those singleton instances that were in the `producers` map hence the JMX `ManagedProducer` that is created when `doGetProducer` invokes {code}getCamelContext().addService(answer, false); {code} is never removed. Since the global pool is empty when the next request to get a producer is called a new producer is created, jmx wrapper and all, whilst the old instance remains orphaned retaining any objects that pertain to that instance. One workaround is for the producer to call {code}getEndpoint().getCamelContext().removeService(this){code} in it's stop method, however this is fairly obscure and it would probably be better to invoke removal of the producer when it is removed from the shared pool. Another issue of note is that when a route is shutdown that contains a SendProcessor due to the shutdown invocation on the SharedProcessorServicePool the global pool is cleared of `everything`. h4. Impact For general use where there is no dynamic creation or passivation of routes this issue should be minimal, however in our use case where the routes are not static, there is a certain amount of recreation of routes as customer endpoints change and there is a need to passivate idle routes this causes a considerable memory leak (via SFTP in particular). h4. Test Case {code} package org.apache.camel.component; import com.google.common.util.concurrent.AtomicLongMap; import org.apache.camel.CamelContext; import org.apache.camel.Consumer; import org.apache.camel.Endpoint; import org.apache.camel.Exchange; import org.apache.camel.Processor; import org.apache.camel.Producer; import org.apache.camel.Route; import org.apache.camel.Service; import org.apache.camel.ServicePoolAware; import org.apache.camel.ServiceStatus; import org.apache.camel.builder.RouteBuilder; import org.apache.camel.impl.DefaultComponent; import org.apache.camel.impl.DefaultEndpoint; import org.apache.camel.impl.DefaultProducer; import org.apache.camel.support.LifecycleStrategySupport; import org.apache.camel.support.ServiceSupport; import org.apache.camel.test.junit4.CamelTestSupport; import org.junit.Test; import java.util.Map; import static com.google.common.base.Preconditions.checkNotNull; /** * Test memory behaviour of producers using {@link ServicePoolAware} when using JMX. */ public class ServicePoolAwareLeakyTest extends CamelTestSupport { private static final String LEAKY_SIEVE_STABLE = "leaky://sieve-stable?plugged=true"; private static final String LEAKY_SIEVE_TRANSIENT = "leaky://sieve-transient?plugged=true"; private static boolean isPatchApplied() { return Boolean.parseBoolean(System.getProperty("patchApplied", "false")); } /** * Component that provides leaks producers. */ private static class LeakySieveComponent extends DefaultComponent { @Override protected Endpoint createEndpoint(String uri, String remaining, Map parameters) throws Exception { boolean plugged = "true".equalsIgnoreCase((String) parameters.remove("plugged")); return new LeakySieveEndpoint(uri, isPatchApplied() && p
[jira] [Resolved] (CAMEL-9141) Salesforce component's LoginToken.java is broken
[ https://issues.apache.org/jira/browse/CAMEL-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9141. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: 2.15.4 Thanks for the PR > Salesforce component's LoginToken.java is broken > > > Key: CAMEL-9141 > URL: https://issues.apache.org/jira/browse/CAMEL-9141 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3 >Reporter: Devendra Khanolkar >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.4 > > > Apparently, Salesforce released a patch to all their non prod env's over the > weekend and that has busted the camel components login. > Here is the error - > Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: > Unrecognized field "is_readonly" (Class > org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as > ignorable > at [Source: [B@3112c01a; line: 1, column: 147] (through reference chain: > org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"]) > I've submitted a pull request - > https://github.com/apache/camel/pull/615 > I've tested it against https://test.salesforce.com, however its worth testing > against https://login.salesforce.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9070) java.lang.IllegalStateException: SENDING => HEADERS
[ https://issues.apache.org/jira/browse/CAMEL-9070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9070: --- Priority: Major (was: Critical) > java.lang.IllegalStateException: SENDING => HEADERS > --- > > Key: CAMEL-9070 > URL: https://issues.apache.org/jira/browse/CAMEL-9070 > Project: Camel > Issue Type: Bug > Components: camel-jetty >Affects Versions: 2.15.2 > Environment: Karaf 3.0.3 >Reporter: Ralf Steppacher > > When using the jetty component in a simple reverse proxy route deployed in > {{Karaf 3.0.3}} I randomly receive the following Stacktrace: > {noformat} > 2015-08-14 10:44:15,931 | WARN | (0x64868d0a)-184 | HttpExchange > | 117 - org.eclipse.jetty.aggregate.jetty-all-server - > 8.1.15.v20140411 | | EXCEPTION > ContentExchange@22d1b2c3=POST//ibb9931:8081/XDS3/repository/repo2#SENDING(1ms)->EXCEPTED(0ms)sent=388ms > org.apache.camel.CamelExchangeException: JettyClient failed cause by: SENDING > => HEADERS. Exchange[HttpMessage@0x4b022edc]. Caused by: > [java.lang.IllegalStateException - SENDING => HEADERS] > at > org.apache.camel.component.jetty8.JettyContentExchange8.doTaskCompleted(JettyContentExchange8.java:210)[150:org.apache.camel.camel-jetty8:2.15.2] > at > org.apache.camel.component.jetty8.JettyContentExchange8.onException(JettyContentExchange8.java:138)[150:org.apache.camel.camel-jetty8:2.15.2] > at > org.apache.camel.component.jetty8.JettyContentExchange8$1.onException(JettyContentExchange8.java:98)[150:org.apache.camel.camel-jetty8:2.15.2] > at > org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:168)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at java.lang.Thread.run(Thread.java:745)[:1.7.0_60] > Caused by: java.lang.IllegalStateException: SENDING => HEADERS > at > org.eclipse.jetty.client.HttpExchange.setStatus(HttpExchange.java:370)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.client.AbstractHttpConnection$Handler.startResponse(AbstractHttpConnection.java:297)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:489)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > at > org.eclipse.jetty.client.AsyncHttpConnection.handle(AsyncHttpConnection.java:135)[120:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] > ... 5 more > {noformat} > I have found (rather old) posts on the web that claim that the behavior is > related to message size. I am {{POST}}-ing about 6kb of SOAP XML with the > following headers: > {noformat} > POST http://localhost:8080/XDS3/repository/repo2 HTTP/1.1 > Accept-Encoding: gzip,deflate > Content-Type: multipart/related; type="application/xop+xml"; > start=""; start-info="application/soap+xml"; > action="urn:ihe:iti:2007:RetrieveDocumentSet"; > boundary="=_Part_139_1471895036.1439218177147" > MIME-Version: 1.0 > Content-Length: 6858 > Host: localhost:8080 > Connection: Keep-Alive > User-Agent: Apache-HttpClient/4.1.1 (java 1.5) > {noformat} > The issue pops up at random but not evenly distributed. It either almost > always happens or hardly ever. Re-installing my bundle or restarting Karaf > usually triggers a switch between the two scenarios on some machines. On > others the error is persistent. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14769021#comment-14769021 ] ASF GitHub Bot commented on CAMEL-9142: --- Github user scranton closed the pull request at: https://github.com/apache/camel/pull/616 > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16.0, 2.15.4 > > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a 'java.lang.RuntimeException: InputStream cannot > be null' for unit tests that have a getBlueprintDescriptor with multiple file > references, i.e. a '+' concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768997#comment-14768997 ] Claus Ibsen commented on CAMEL-9142: Thanks for the patch Scott. > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > Fix For: 2.16.0, 2.15.4 > > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a 'java.lang.RuntimeException: InputStream cannot > be null' for unit tests that have a getBlueprintDescriptor with multiple file > references, i.e. a '+' concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9142. Resolution: Fixed Assignee: Claus Ibsen > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16.0, 2.15.4 > > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a 'java.lang.RuntimeException: InputStream cannot > be null' for unit tests that have a getBlueprintDescriptor with multiple file > references, i.e. a '+' concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9142: --- Fix Version/s: 2.15.4 2.16.0 > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > Fix For: 2.16.0, 2.15.4 > > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a 'java.lang.RuntimeException: InputStream cannot > be null' for unit tests that have a getBlueprintDescriptor with multiple file > references, i.e. a '+' concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9142: --- Component/s: camel-test > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug > Components: camel-test >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > Fix For: 2.16.0, 2.15.4 > > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a 'java.lang.RuntimeException: InputStream cannot > be null' for unit tests that have a getBlueprintDescriptor with multiple file > references, i.e. a '+' concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8587) Exceptions from multicast aggregators are not propagated to the global exception handler
[ https://issues.apache.org/jira/browse/CAMEL-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8587. Resolution: Cannot Reproduce > Exceptions from multicast aggregators are not propagated to the global > exception handler > > > Key: CAMEL-8587 > URL: https://issues.apache.org/jira/browse/CAMEL-8587 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.15.1 >Reporter: Pavel Drasil >Assignee: Claus Ibsen > Fix For: 2.16.0 > > Attachments: MyAggregator.java, camel-context.xml > > > When a multicast aggregator throws an exception, either directly or by > setting the exception to the returned exchange, the exception is just logged > instead of being propagated to the global exception handler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8587) Exceptions from multicast aggregators are not propagated to the global exception handler
[ https://issues.apache.org/jira/browse/CAMEL-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768921#comment-14768921 ] Claus Ibsen commented on CAMEL-8587: If an exception is thrown from the aggregate method in the AggregationStrategy, then by default, that exception is not handled by the error handler. The error handler can be enabled to react if enabling the shareUnitOfWork option. > Exceptions from multicast aggregators are not propagated to the global > exception handler > > > Key: CAMEL-8587 > URL: https://issues.apache.org/jira/browse/CAMEL-8587 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.15.1 >Reporter: Pavel Drasil >Assignee: Claus Ibsen > Fix For: 2.16.0 > > Attachments: MyAggregator.java, camel-context.xml > > > When a multicast aggregator throws an exception, either directly or by > setting the exception to the returned exchange, the exception is just logged > instead of being propagated to the global exception handler. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cranton updated CAMEL-9142: - Description: Looks like update CAMEL-8948 dropped support for multiple blueprint descriptors within CamelBlueprintTestSupport file within camel-test-blueprint component. The symptom is a 'java.lang.RuntimeException: InputStream cannot be null' for unit tests that have a getBlueprintDescriptor with multiple file references, i.e. a '+' concatenating two or more descriptor files. (was: Looks like update CAMEL-8948 dropped support for multiple blueprint descriptors within CamelBlueprintTestSupport file within camel-test-blueprint component. The symptom is a null input stream for unit tests that have a getBlueprintDescriptor with multiple file references, i.e. a '+' concatenating two or more descriptor files.) > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a 'java.lang.RuntimeException: InputStream cannot > be null' for unit tests that have a getBlueprintDescriptor with multiple file > references, i.e. a '+' concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8393) Redelivery doesn't work correctly on Dynamic Routers
[ https://issues.apache.org/jira/browse/CAMEL-8393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8393. Resolution: Fixed Thanks for reporting > Redelivery doesn't work correctly on Dynamic Routers > > > Key: CAMEL-8393 > URL: https://issues.apache.org/jira/browse/CAMEL-8393 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.1 > Environment: mac >Reporter: Minh Tran >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > When redelivery occurs for dynamic routers, the properties are being kept. So > if the dynamic router uses a property to store the current state such as used > in example http://camel.apache.org/dynamic-router.html , then the redelivery > actually ends up skipping the endpoint that caused the exception > Here is my dynamic router class > {noformat} > public class Router { > public String route(Exchange exchange) { > Boolean invoked = exchange.getProperty("invoked", > Boolean.class); > if (invoked == null) { > exchange.setProperty("invoked", true); > return "mock:route"; > } else > return null; > } > } > {noformat} > Here is my unit test class > {noformat} > @RunWith(CamelSpringJUnit4ClassRunner.class) > @ContextConfiguration(loader = CamelSpringDelegatingTestContextLoader.class) > public class DynamicRouterTest { > @Produce(uri = "direct:start") > private ProducerTemplate producerTemplate; > @EndpointInject(uri = "mock:end") > private MockEndpoint end; > @EndpointInject(uri = "mock:route") > private MockEndpoint route; > @Configuration > public static class JavaConfig extends SingleRouteCamelConfiguration { > @Override > public RouteBuilder route() { > return new SpringRouteBuilder() { > @Override > public void configure() throws Exception { > this.getContext().setTracing(true); > > from("direct:start").onException(IOException.class).maximumRedeliveries(-1).end() > > .dynamicRouter().method(Router.class).to("mock:end"); > } > }; > } > } > @Test > public void test() throws InterruptedException { > route.whenAnyExchangeReceived(new Processor() { > @Override > public void process(Exchange exchange) throws Exception > { > exchange.getIn().setBody("mock route"); > } > }); > route.expectedBodiesReceived("before"); > end.expectedBodiesReceived("mock route"); > producerTemplate.sendBody("before"); > route.assertIsSatisfied(); > end.assertIsSatisfied(); > } > @Test > public void test_exception() throws InterruptedException { > route.whenExchangeReceived(1, new Processor() { > @Override > public void process(Exchange exchange) throws Exception > { > exchange.setException(new IOException()); > } > }); > route.whenExchangeReceived(2, new Processor() { > @Override > public void process(Exchange exchange) throws Exception > { > exchange.getIn().setBody("mock route"); > } > }); > // this bit fails > route.expectedBodiesReceived("before", "before"); > end.expectedBodiesReceived("mock route"); > producerTemplate.sendBody("before"); > route.assertIsSatisfied(); > end.assertIsSatisfied(); > } > } > {noformat} > The test method runs successfully but the test_exception method which tests > the redelivery does not. Fails with "java.lang.AssertionError: mock://route > Received message count. Expected: <2> but was: <1>" which shows that the > dynamic router only called the mock:route once. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9097. Resolution: Fixed > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9119) XSLT errors should not be ignored
[ https://issues.apache.org/jira/browse/CAMEL-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9119. Resolution: Fixed > XSLT errors should not be ignored > - > > Key: CAMEL-9119 > URL: https://issues.apache.org/jira/browse/CAMEL-9119 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 > Environment: ServiceMix 5.4.1 >Reporter: metatech >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.4 > > Attachments: camel_xslt_errors_thrown.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err. > Unfortunately, the XsltErrorHandler which was introduced does not behave as > the default ErrorHandler which logs on System.err and re-throws exceptions > (my mistake). > The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise > they are ignored and the service is allowed to start, although the XSLT > transformation is not successfully started. > Here is a small patch that fixes that. > The test "XsltTestErrorListenerTest" is still successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cranton updated CAMEL-9142: - Description: Looks like update CAMEL-8948 dropped support for multiple blueprint descriptors within CamelBlueprintTestSupport file within camel-test-blueprint component. The symptom is a null input stream for unit tests that have a getBlueprintDescriptor with multiple file references, i.e. a '+' concatenating two or more descriptor files. > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > > Looks like update CAMEL-8948 dropped support for multiple blueprint > descriptors within CamelBlueprintTestSupport file within camel-test-blueprint > component. The symptom is a null input stream for unit tests that have a > getBlueprintDescriptor with multiple file references, i.e. a '+' > concatenating two or more descriptor files. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9119) XSLT errors should not be ignored
[ https://issues.apache.org/jira/browse/CAMEL-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768889#comment-14768889 ] Claus Ibsen commented on CAMEL-9119: Okay seems it was another ticket that had a knock-on effect on this. JDK vs Saxon behaves different and report different errors etc. > XSLT errors should not be ignored > - > > Key: CAMEL-9119 > URL: https://issues.apache.org/jira/browse/CAMEL-9119 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 > Environment: ServiceMix 5.4.1 >Reporter: metatech >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.4 > > Attachments: camel_xslt_errors_thrown.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err. > Unfortunately, the XsltErrorHandler which was introduced does not behave as > the default ErrorHandler which logs on System.err and re-throws exceptions > (my mistake). > The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise > they are ignored and the service is allowed to start, although the XSLT > transformation is not successfully started. > Here is a small patch that fixes that. > The test "XsltTestErrorListenerTest" is still successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1476#comment-1476 ] Claus Ibsen commented on CAMEL-9097: Yep only the test > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768886#comment-14768886 ] Raúl Kripalani commented on CAMEL-9097: --- Sounds like a plan. Will you take care of it, then? Just the test, right? We want the strategy to remain in camel-core so that folks running processors other than Xalan or Saxon can also use it without importing camel-saxon. Thanks. > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768878#comment-14768878 ] Claus Ibsen commented on CAMEL-9097: Okay moving the xslt test to camel-saxon should be the right solution which I am doing now. > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768873#comment-14768873 ] Raúl Kripalani commented on CAMEL-9097: --- Thanks, Claus. I'll have a look. It doesn't break anything in Camel – though. I had to add Saxon because of this old bug in Xalan which affects the unit tests for this new Aggr. Strategy: https://issues.apache.org/jira/browse/XALANJ-2057. > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768868#comment-14768868 ] ASF GitHub Bot commented on CAMEL-9142: --- GitHub user scranton opened a pull request: https://github.com/apache/camel/pull/616 CAMEL-9142: added back support for multiple blueprint descriptors in … …camel-test-blueprint You can merge this pull request into a Git repository by running: $ git pull https://github.com/scranton/camel CAMEL-9142 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/616.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 #616 commit 4f212df06867c7b7b4fd63e465080399c54ee6dc Author: Scott Cranton Date: 2015-09-16T12:39:07Z CAMEL-9142: added back support for multiple blueprint descriptors in camel-test-blueprint > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
[ https://issues.apache.org/jira/browse/CAMEL-9142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Cranton updated CAMEL-9142: - Patch Info: Patch Available > dropped support for multiple blueprint descriptors in unit tests > > > Key: CAMEL-9142 > URL: https://issues.apache.org/jira/browse/CAMEL-9142 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3 >Reporter: Scott Cranton >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768845#comment-14768845 ] Claus Ibsen commented on CAMEL-9097: This causes many unit tests errors in camel-core - I guess because you add saxon {code} Tests in error: DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextDualNamespaces:79 » UnsupportedOperation DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextParent:98 » UnsupportedOperation DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextPre:58 » UnsupportedOperation DefaultNamespaceContextTest>TestSupport.runBare:58->testDefaultNamespaceContextEmpty:39 » UnsupportedOperation XPathFeatureTest>TestSupport.runBare:58->testXPathResult:46 » NullPointer XsltRouteAllowStAXTest>TestSupport.runBare:58->XsltRouteTest.testSendBytesMessage:37->XsltRouteTest.sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteAllowStAXTest>TestSupport.runBare:58->XsltRouteTest.testSendDomMessage:43->XsltRouteTest.sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteAllowStAXTest>TestSupport.runBare:58->XsltRouteTest.testSendStringMessage:33->XsltRouteTest.sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteFileTest>TestSupport.runBare:58->XsltRouteTest.testSendBytesMessage:37->XsltRouteTest.sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteFileTest>TestSupport.runBare:58->XsltRouteTest.testSendDomMessage:43->XsltRouteTest.sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteFileTest>TestSupport.runBare:58->XsltRouteTest.testSendStringMessage:33->XsltRouteTest.sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteTest>TestSupport.runBare:58->testSendBytesMessage:37->sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteTest>TestSupport.runBare:58->testSendDomMessage:43->sendMessageAndHaveItTransformed:50 » CamelExecution XsltRouteTest>TestSupport.runBare:58->testSendStringMessage:33->sendMessageAndHaveItTransformed:50 » CamelExecution AsyncLoopTest>TestSupport.runBare:58->testExpressionClauseLoop:46->performLoopTest:87->performLoopTest:82 » CamelExecution LoopTest>TestSupport.runBare:58->testExpressionClauseLoop:40->performLoopTest:70->performLoopTest:65 » CamelExecution ToDynamicLanguageSimpleAndXPathAndHeaderTest>TestSupport.runBare:58->testToDynamic:28 » CamelExecution ToDynamicLanguageSimpleAndXPathTest>TestSupport.runBare:58->testToDynamic:28 » CamelExecution ToDynamicLanguageXPathTest>TestSupport.runBare:58->testToDynamic:28 » CamelExecution {code} > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CAMEL-9097) XSLT Aggregation Strategy
[ https://issues.apache.org/jira/browse/CAMEL-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reopened CAMEL-9097: > XSLT Aggregation Strategy > - > > Key: CAMEL-9097 > URL: https://issues.apache.org/jira/browse/CAMEL-9097 > Project: Camel > Issue Type: New Feature >Reporter: Ranil Wijeyratne >Assignee: Raúl Kripalani >Priority: Minor > Labels: aggregate, xslt > Fix For: 2.16.0 > > > It would be great to have an built in aggregation strategy that allows to use > an xsl stylesheet to aggregate messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9142) dropped support for multiple blueprint descriptors in unit tests
Scott Cranton created CAMEL-9142: Summary: dropped support for multiple blueprint descriptors in unit tests Key: CAMEL-9142 URL: https://issues.apache.org/jira/browse/CAMEL-9142 Project: Camel Issue Type: Bug Affects Versions: 2.15.3 Reporter: Scott Cranton Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9141) Salesforce component's LoginToken.java is broken
[ https://issues.apache.org/jira/browse/CAMEL-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devendra Khanolkar updated CAMEL-9141: -- Affects Version/s: 2.15.3 Fix Version/s: 2.16.0 > Salesforce component's LoginToken.java is broken > > > Key: CAMEL-9141 > URL: https://issues.apache.org/jira/browse/CAMEL-9141 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.3 >Reporter: Devendra Khanolkar > Fix For: 2.16.0 > > > Apparently, Salesforce released a patch to all their non prod env's over the > weekend and that has busted the camel components login. > Here is the error - > Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: > Unrecognized field "is_readonly" (Class > org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as > ignorable > at [Source: [B@3112c01a; line: 1, column: 147] (through reference chain: > org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"]) > I've submitted a pull request - > https://github.com/apache/camel/pull/615 > I've tested it against https://test.salesforce.com, however its worth testing > against https://login.salesforce.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9141) Salesforce component's LoginToken.java is broken
Devendra Khanolkar created CAMEL-9141: - Summary: Salesforce component's LoginToken.java is broken Key: CAMEL-9141 URL: https://issues.apache.org/jira/browse/CAMEL-9141 Project: Camel Issue Type: Bug Reporter: Devendra Khanolkar Apparently, Salesforce released a patch to all their non prod env's over the weekend and that has busted the camel components login. Here is the error - Caused by: org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field "is_readonly" (Class org.apache.camel.component.salesforce.internal.dto.LoginToken), not marked as ignorable at [Source: [B@3112c01a; line: 1, column: 147] (through reference chain: org.apache.camel.component.salesforce.internal.dto.LoginToken["is_readonly"]) I've submitted a pull request - https://github.com/apache/camel/pull/615 I've tested it against https://test.salesforce.com, however its worth testing against https://login.salesforce.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CAMEL-9119) XSLT errors should not be ignored
[ https://issues.apache.org/jira/browse/CAMEL-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reopened CAMEL-9119: > XSLT errors should not be ignored > - > > Key: CAMEL-9119 > URL: https://issues.apache.org/jira/browse/CAMEL-9119 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 > Environment: ServiceMix 5.4.1 >Reporter: metatech >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.4 > > Attachments: camel_xslt_errors_thrown.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err. > Unfortunately, the XsltErrorHandler which was introduced does not behave as > the default ErrorHandler which logs on System.err and re-throws exceptions > (my mistake). > The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise > they are ignored and the service is allowed to start, although the XSLT > transformation is not successfully started. > Here is a small patch that fixes that. > The test "XsltTestErrorListenerTest" is still successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9119) XSLT errors should not be ignored
[ https://issues.apache.org/jira/browse/CAMEL-9119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747376#comment-14747376 ] Claus Ibsen commented on CAMEL-9119: This causes side-effects - looking into reverting this > XSLT errors should not be ignored > - > > Key: CAMEL-9119 > URL: https://issues.apache.org/jira/browse/CAMEL-9119 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.3 > Environment: ServiceMix 5.4.1 >Reporter: metatech >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.4 > > Attachments: camel_xslt_errors_thrown.patch > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Since CAMEL-4396, XSLT exceptions are not logged anymore on System.err. > Unfortunately, the XsltErrorHandler which was introduced does not behave as > the default ErrorHandler which logs on System.err and re-throws exceptions > (my mistake). > The XsltErrorHandler should re-throw exceptions for ERROR or FATAL, otherwise > they are ignored and the service is allowed to start, although the XSLT > transformation is not successfully started. > Here is a small patch that fixes that. > The test "XsltTestErrorListenerTest" is still successful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9140) Missing configuration properties in camel-facebook
[ https://issues.apache.org/jira/browse/CAMEL-9140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747329#comment-14747329 ] ASF GitHub Bot commented on CAMEL-9140: --- Github user manuelh9r closed the pull request at: https://github.com/apache/camel/pull/613 > Missing configuration properties in camel-facebook > -- > > Key: CAMEL-9140 > URL: https://issues.apache.org/jira/browse/CAMEL-9140 > Project: Camel > Issue Type: Bug > Components: camel-facebook >Affects Versions: 2.16.0 >Reporter: Manuel Holzleitner >Assignee: Andrea Cosentino > Fix For: 2.16.0 > > > For the new request methods that were introduced with the Facebook4j 2.x > version (see CAMEL-7634) some new parameter arguments are required but were > not added to the endpoint configuration (e.g. pageId for getPage) and thus > endpoints for this methods fail to resolve. > For example, the following does not work: facebook://getPage?pageId=6538157161 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8943) camel-jetty should use jetty9 as default
[ https://issues.apache.org/jira/browse/CAMEL-8943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747079#comment-14747079 ] Claus Ibsen commented on CAMEL-8943: There may be some other components using camel-jetty for testing that may rely on it was version 8. So an idea is to build all the code and also unit test those modules that are using camel-jetty. > camel-jetty should use jetty9 as default > > > Key: CAMEL-8943 > URL: https://issues.apache.org/jira/browse/CAMEL-8943 > Project: Camel > Issue Type: Improvement > Components: camel-jetty >Reporter: Claus Ibsen > Fix For: 2.16.0 > > > We should use jetty 9 as the default jetty version -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9140) Missing configuration properties in camel-facebook
[ https://issues.apache.org/jira/browse/CAMEL-9140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9140: --- Fix Version/s: 2.16.0 > Missing configuration properties in camel-facebook > -- > > Key: CAMEL-9140 > URL: https://issues.apache.org/jira/browse/CAMEL-9140 > Project: Camel > Issue Type: Bug > Components: camel-facebook >Affects Versions: 2.16.0 >Reporter: Manuel Holzleitner >Assignee: Andrea Cosentino > Fix For: 2.16.0 > > > For the new request methods that were introduced with the Facebook4j 2.x > version (see CAMEL-7634) some new parameter arguments are required but were > not added to the endpoint configuration (e.g. pageId for getPage) and thus > endpoints for this methods fail to resolve. > For example, the following does not work: facebook://getPage?pageId=6538157161 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9139) Reading parameter not configurable via header in camel-facebook
[ https://issues.apache.org/jira/browse/CAMEL-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9139: --- Fix Version/s: 2.16.0 > Reading parameter not configurable via header in camel-facebook > --- > > Key: CAMEL-9139 > URL: https://issues.apache.org/jira/browse/CAMEL-9139 > Project: Camel > Issue Type: Bug > Components: camel-facebook >Affects Versions: 2.16.0 >Reporter: Manuel Holzleitner >Assignee: Andrea Cosentino > Fix For: 2.16.0 > > > The reading parameter in camel-facebook can not be configured via an exchange > header as described in the documentation: > bq. The reading option can be a reference or value of type > facebook4j.Reading, or can be specified using the following reading options > in either the endpoint URI *or exchange header with CamelFacebook. prefix*. -- This message was sent by Atlassian JIRA (v6.3.4#6332)