[jira] [Commented] (CAMEL-14680) javax -> jakarta
[ https://issues.apache.org/jira/browse/CAMEL-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17054365#comment-17054365 ] David J. M. Karlsen commented on CAMEL-14680: - Spring-Boot seems to move in 2.2: https://github.com/spring-projects/spring-boot/issues/16111 and cxf in 3.4: https://github.com/apache/cxf/pull/500/files > javax -> jakarta > > > Key: CAMEL-14680 > URL: https://issues.apache.org/jira/browse/CAMEL-14680 > Project: Camel > Issue Type: Task >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > When the industry switches from javax to jarkarta then we should follow up as > well. > Its mostly JMS, Servlet, Mail, CDI, WS, JAX-RS, and other components. So at > some day we may have a release that switches fully over and is not backwards > compatible. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14621) Camel-spring-boot-starters have unnecessary JAX-B and JAX-WS dependencies on Java 11
[
https://issues.apache.org/jira/browse/CAMEL-14621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047047#comment-17047047
]
David J. M. Karlsen commented on CAMEL-14621:
-
+1.
That's a bit of exclude-pain going on in my pom's.
Also - I think it's good to move to jakarta.* based dependencies rather than
javax.* etc - since the community seems to go in that direction.
> Camel-spring-boot-starters have unnecessary JAX-B and JAX-WS dependencies on
> Java 11
>
>
> Key: CAMEL-14621
> URL: https://issues.apache.org/jira/browse/CAMEL-14621
> Project: Camel
> Issue Type: Bug
> Components: camel-spring-boot-starters
>Affects Versions: 3.1.0
>Reporter: Pascal Schumacher
>Priority: Minor
> Fix For: 3.2.0
>
>
> In Version 3.1.0 every camel-spring-boot-starter has (a lot) of unnecessary
> JAX-B and JAX-WS dependencies when used with Java 11. E.g.:
> {noformat}
> [INFO] +-
> org.apache.camel.springboot:camel-micrometer-starter:jar:3.1.0:compile
> [INFO] | +- org.apache.camel:camel-micrometer:jar:3.1.0:compile
> [INFO] | +-
> org.apache.camel.springboot:camel-spring-boot-starter:jar:3.1.0:compile
> [INFO] | +- javax.annotation:javax.annotation-api:jar:1.3.2:compile
> [INFO] | +- javax.xml.ws:jaxws-api:jar:2.3.1:compile
> [INFO] | +- jakarta.xml.bind:jakarta.xml.bind-api:jar:2.3.2:compile
> [INFO] | | \- jakarta.activation:jakarta.activation-api:jar:1.2.1:compile
> [INFO] | +-
> org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1.1.3:compile
> [INFO] | +- com.sun.xml.messaging.saaj:saaj-impl:jar:1.5.1:compile
> [INFO] | | +- jakarta.xml.soap:jakarta.xml.soap-api:jar:1.4.1:compile
> [INFO] | | \- org.jvnet.mimepull:mimepull:jar:1.9.12:compile
> [INFO] | +- org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile
> [INFO] | +-
> org.jboss.spec.javax.rmi:jboss-rmi-api_1.0_spec:jar:1.0.6.Final:compile
> [INFO] | +- org.glassfish.jaxb:jaxb-runtime:jar:2.3.2:compile
> [INFO] | | +- org.glassfish.jaxb:txw2:jar:2.3.2:compile
> [INFO] | | +- com.sun.istack:istack-commons-runtime:jar:3.0.8:compile
> [INFO] | | +- org.jvnet.staxex:stax-ex:jar:1.8.1:compile
> [INFO] | | \- com.sun.xml.fastinfoset:FastInfoset:jar:1.2.16:compile
> [INFO] | \- javax.xml.soap:javax.xml.soap-api:jar:1.4.0:compile
> {noformat}
> It is the same for other starters.
> I think the cause is that the Java9+ profile of the camel-spring-boot/pom.xml
> (see:
> https://github.com/apache/camel-spring-boot/blob/5c8d1e30fe8df62382a264def38c9d827bd8cfb9/pom.xml#L765)
> which is an ancestor of every camel-spring-boot-stater adds the JAX-WS and
> JAX-B dependencies.
> This wasn't the case in Camel 3.0.1/3.0.0/2.24.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-14182) Hystrix EIP in model should be neutral and allow plugin for other implementations
[ https://issues.apache.org/jira/browse/CAMEL-14182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974494#comment-16974494 ] David J. M. Karlsen commented on CAMEL-14182: - that makes sense - however take note that hystrix is not actively developed any longer. > Hystrix EIP in model should be neutral and allow plugin for other > implementations > - > > Key: CAMEL-14182 > URL: https://issues.apache.org/jira/browse/CAMEL-14182 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-14079) Upgrade to Jetty 9.4.21.v20190926
[ https://issues.apache.org/jira/browse/CAMEL-14079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16954372#comment-16954372 ] David J. M. Karlsen commented on CAMEL-14079: - https://github.com/eclipse/jetty.project/issues/4141 (don't be mislead by the heading). > Upgrade to Jetty 9.4.21.v20190926 > - > > Key: CAMEL-14079 > URL: https://issues.apache.org/jira/browse/CAMEL-14079 > Project: Camel > Issue Type: Task > Components: camel-jetty >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13383) maven plugi validation fails with 3.0.0m1/m2
[
https://issues.apache.org/jira/browse/CAMEL-13383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16806632#comment-16806632
]
David J. M. Karlsen commented on CAMEL-13383:
-
{code}
public class DhubUploadRouteBuilder extends RouteBuilder {
static final String UPLOAD_ENDPOINT = "direct:uploadEndpoint";
@Override
public void configure() throws Exception {
from(UPLOAD_ENDPOINT)
.id("dhubUploadRoute")
.streamCaching()
.tracing()
.convertBodyTo(InputStream.class)
.choice()
.when()
.simple("properties:dhub.export.doUpload:false")
.to("{{dhub.export.uploadUri}}")
.otherwise()
.log(LoggingLevel.WARN, "Upload Disabled!");
{code}
> maven plugi validation fails with 3.0.0m1/m2
>
>
> Key: CAMEL-13383
> URL: https://issues.apache.org/jira/browse/CAMEL-13383
> Project: Camel
> Issue Type: Bug
> Components: tooling
>Affects Versions: 3.0.0-M2, 3.0.0-M1
>Reporter: David J. M. Karlsen
>Priority: Major
>
> The camel plugin fails validation which passed fine in v2.latest.
> Also from the error-message it is not easy to understand what is really the
> problem?
> {noformat}
> INFO] [jenkins-event-spy] Generated
> /data/jenkins/workspace/c-jfr-server_feature_camel3-Y6VPXEFM3D7D7C2V3GQRGLFL7QLPEWEFUJY6V6RFK46FIDVYQ7SQ@tmp/withMavenca46cdd5/maven-spy-20190401-102256-4351026941413226375350.log
> [ERROR] Failed to execute goal
> org.apache.camel:camel-report-maven-plugin:3.0.0-M2:validate (default) on
> project jfr-srv-batch: Endpoint validation success: (1 = passed, 0 = invalid,
> 1 = incapable, 0 = unknown components, 0 = deprecated options)
> [ERROR] Simple validation error: (0 = passed, 1 = invalid)
> [ERROR] Duplicate route id validation success (0 = ids)
> [ERROR] Endpoint pair (seda/direct) validation success (0 = pairs)
> [ERROR] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.camel:camel-report-maven-plugin:3.0.0-M2:validate (default)
> on project jfr-srv-batch: Endpoint validation success: (1 = passed, 0 =
> invalid, 1 = incapable, 0 = unknown components, 0 = deprecated options)
> Simple validation error: (0 = passed, 1 = invalid)
> Duplicate route id validation success (0 = ids)
> Endpoint pair (seda/direct) validation success (0 = pairs)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:196)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call
> (Executors.java:515)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker
> (ThreadPoolExecutor.java:1128)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:628)
> at java.lang.Thread.run (Thread.java:835)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Endpoint
> validation success: (1 = passed, 0 = invalid, 1 = incapable, 0 = unknown
> components, 0 = deprecated options)
> Simple validation error: (0 = passed, 1 = invalid)
> Duplicate route id validation success (0 = ids)
> Endpoint pair (seda/direct) validation success (0 = pairs)
> at org.apache.camel.maven.ValidateMojo.execute (ValidateMojo.java:484)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:200)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> (MultiThreadedBuilder.java:196)
> at java.util.concurrent.FutureTask.run (FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call
>
[jira] [Created] (CAMEL-13383) maven plugi validation fails with 3.0.0m1/m2
David J. M. Karlsen created CAMEL-13383:
---
Summary: maven plugi validation fails with 3.0.0m1/m2
Key: CAMEL-13383
URL: https://issues.apache.org/jira/browse/CAMEL-13383
Project: Camel
Issue Type: Bug
Components: tooling
Affects Versions: 3.0.0-M1, 3.0.0-M2
Reporter: David J. M. Karlsen
The camel plugin fails validation which passed fine in v2.latest.
Also from the error-message it is not easy to understand what is really the
problem?
{noformat}
INFO] [jenkins-event-spy] Generated
/data/jenkins/workspace/c-jfr-server_feature_camel3-Y6VPXEFM3D7D7C2V3GQRGLFL7QLPEWEFUJY6V6RFK46FIDVYQ7SQ@tmp/withMavenca46cdd5/maven-spy-20190401-102256-4351026941413226375350.log
[ERROR] Failed to execute goal
org.apache.camel:camel-report-maven-plugin:3.0.0-M2:validate (default) on
project jfr-srv-batch: Endpoint validation success: (1 = passed, 0 = invalid, 1
= incapable, 0 = unknown components, 0 = deprecated options)
[ERROR] Simple validation error: (0 = passed, 1 = invalid)
[ERROR] Duplicate route id validation success (0 = ids)
[ERROR] Endpoint pair (seda/direct) validation success (0 = pairs)
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.camel:camel-report-maven-plugin:3.0.0-M2:validate (default) on
project jfr-srv-batch: Endpoint validation success: (1 = passed, 0 = invalid, 1
= incapable, 0 = unknown components, 0 = deprecated options)
Simple validation error: (0 = passed, 1 = invalid)
Duplicate route id validation success (0 = ids)
Endpoint pair (seda/direct) validation success (0 = pairs)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:200)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:835)
Caused by: org.apache.maven.plugin.MojoExecutionException: Endpoint validation
success: (1 = passed, 0 = invalid, 1 = incapable, 0 = unknown components, 0 =
deprecated options)
Simple validation error: (0 = passed, 1 = invalid)
Duplicate route id validation success (0 = ids)
Endpoint pair (seda/direct) validation success (0 = pairs)
at org.apache.camel.maven.ValidateMojo.execute (ValidateMojo.java:484)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:200)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:196)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
at java.lang.Thread.run (Thread.java:835)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12968) DefaultFluentProducerTemplate is not thread safe (endpoint, etc.)
[
https://issues.apache.org/jira/browse/CAMEL-12968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704798#comment-16704798
]
David J. M. Karlsen commented on CAMEL-12968:
-
Did you test with 2.23.0? It contained a threadsafe fix for the said class.
> DefaultFluentProducerTemplate is not thread safe (endpoint, etc.)
> -
>
> Key: CAMEL-12968
> URL: https://issues.apache.org/jira/browse/CAMEL-12968
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.22.1, 2.23.0
>Reporter: Paul D Johe
>Priority: Major
>
> The DefaultFluentProducerTemplate saves state between method calls. This
> leads to unexpected behavior when the javadoc specifies that it should be
> thread safe.
> For example:
> # thread 1 calls fluentProducerTemplate.to("direct:a").send("message1");
> # thread 2 calls fluentProducerTemplate.to("direct:b").send("message2");
> If these are run in parallel, the sequence of calls can be:
> # thread 1 calls to("direct:a") - endpoint in the object is direct:a
> # thread 2 calls to("direct:b") - endpoint in the object is direct:b
> # *thread 1 calls send("message1") - this gets sent incorrectly to direct:b*
> # thread 2 calls send("message2") - this gets sent correctly to direct:b
> Endpoint is one example, but almost all fields in this class share this
> behavior. It should be clearly documented which fields can be used fluently
> over multiple threads, and which cannot. As the API is today, all methods
> returning 'this' should be made thread-safe (state is only local to the
> caller) so that the fluent interface works as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-11807) Upgrade to JUnit 5
[ https://issues.apache.org/jira/browse/CAMEL-11807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661396#comment-16661396 ] David J. M. Karlsen commented on CAMEL-11807: - one thing is internally in camel - but it would be good to offer an alternative to CamelSpringRunner to consumers of the framework - so that they could move to junit5. > Upgrade to JUnit 5 > -- > > Key: CAMEL-11807 > URL: https://issues.apache.org/jira/browse/CAMEL-11807 > Project: Camel > Issue Type: Improvement >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.0.0, Future > > > See http://junit.org/junit5/ > Note: it provides a junit-vintage module so we should be able to migrate > stuffs easily (!) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12363) Upgrade to spring batch 4.x
[ https://issues.apache.org/jira/browse/CAMEL-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen updated CAMEL-12363: Priority: Minor (was: Major) > Upgrade to spring batch 4.x > --- > > Key: CAMEL-12363 > URL: https://issues.apache.org/jira/browse/CAMEL-12363 > Project: Camel > Issue Type: Improvement > Components: camel-spring-batch >Reporter: David J. M. Karlsen >Priority: Minor > Fix For: 2.22.0 > > > Upgrade to spring batch 4.x (which is spring 5.x based) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12363) Upgrade to spring batch 4.x
[ https://issues.apache.org/jira/browse/CAMEL-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen resolved CAMEL-12363. - Resolution: Fixed > Upgrade to spring batch 4.x > --- > > Key: CAMEL-12363 > URL: https://issues.apache.org/jira/browse/CAMEL-12363 > Project: Camel > Issue Type: Improvement > Components: camel-spring-batch >Reporter: David J. M. Karlsen >Priority: Major > Fix For: 2.22.0 > > > Upgrade to spring batch 4.x (which is spring 5.x based) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12363) Upgrade to spring batch 4.x
David J. M. Karlsen created CAMEL-12363: --- Summary: Upgrade to spring batch 4.x Key: CAMEL-12363 URL: https://issues.apache.org/jira/browse/CAMEL-12363 Project: Camel Issue Type: Improvement Components: camel-spring-batch Reporter: David J. M. Karlsen Fix For: 2.22.0 Upgrade to spring batch 4.x (which is spring 5.x based) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-11756) camel-spring-boot2 - Create experimental spring boot 2 component
[ https://issues.apache.org/jira/browse/CAMEL-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16280857#comment-16280857 ] David J. M. Karlsen commented on CAMEL-11756: - Is the version a bit misleading? It looks like the component should be in 2.20.0 - but I guess it is just the boot2 branch which was taken while 2.20.0 was in the making and it has not been integrated into any version yet. > camel-spring-boot2 - Create experimental spring boot 2 component > > > Key: CAMEL-11756 > URL: https://issues.apache.org/jira/browse/CAMEL-11756 > Project: Camel > Issue Type: Task > Components: camel-spring-boot >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.20.0 > > > We should try get started with the migration effort for getting Camel running > on Spring Boot 2.0.x. > There may be issues with the starter component as Spring Boot guys changed > stuff how auto configuration and setting properties works. So we may need to > have some kind of interface in camel-spring-boot and camel-spring-boot2 where > we can have different implementation that the -starter can use. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11822) Upgade jaxb-core
[ https://issues.apache.org/jira/browse/CAMEL-11822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16193542#comment-16193542 ] David J. M. Karlsen commented on CAMEL-11822: - does it require JDK9? https://javaee.github.io/jaxb-v2/doc/user-guide/release-documentation.html#a-2-3-0 > Upgade jaxb-core > > > Key: CAMEL-11822 > URL: https://issues.apache.org/jira/browse/CAMEL-11822 > Project: Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen > Fix For: 2.21.0 > > > We are using 2.2.11 but there is a newer 2.3.0 release out. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11623) LevelDB Java implementation wont be tried on Errors
[ https://issues.apache.org/jira/browse/CAMEL-11623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112439#comment-16112439 ] David J. M. Karlsen commented on CAMEL-11623: - It's probably close enough. I am nitpicking a bit anyways - catching LinkageError will narrow it quite a bit to what was originally thought. > LevelDB Java implementation wont be tried on Errors > --- > > Key: CAMEL-11623 > URL: https://issues.apache.org/jira/browse/CAMEL-11623 > Project: Camel > Issue Type: Bug > Components: camel-leveldb >Affects Versions: 2.19.2 >Reporter: Mart Kartašev > Fix For: 2.18.5, 2.20.0, 2.19.3 > > > For a bit of background, we have been running into a problem with the LevelDB > JNI drivers for AggregationRepositories, which prevents startup when using > routes for which we require persistent aggregation. This, however, is not the > main topic of this issue. > In the latest version (2.19.2) the following issue has implemented a Java > specific leveldb factory: > https://issues.apache.org/jira/browse/CAMEL-11427 > The relevant part of the Error on startup is as follows: > java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no > leveldbjni64-1.8 in java.library.path, no leveldbjni-1.8 in > java.library.path, no leveldbjni in java.library.path, > C:\Users\atos\AppData\Local\Temp\leveldbjni-64-1-794362262645531032.8: Can't > find dependent libraries] > at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182) > at org.fusesource.hawtjni.runtime.Library.load(Library.java:140) > at org.fusesource.leveldbjni.JniDBFactory.(JniDBFactory.java:48) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:442) > at > org.apache.camel.component.leveldb.LevelDBFile.getFactory(LevelDBFile.java:189) > > at org.apache.camel.component.leveldb.LevelDBFile.start(LevelDBFile.java:174) > The way that I understand the code added in issue 11427, is that the > LevelDBFile class getFactory() method (line 181) will first try to initiate > with the JNI drivers and if that fails, will turn to the pure Java > implementation. This is done by catching an Exception which is then ignored > incase the JNI driver fails. > However, when we look at the code we see that UnstatisfiedLinkError does not > extend Exception, it extends Error. > This Error is therefore not caught by the application and thus the Java > implementation for LevelDB is never even attempted to be initialized as the > method execution ends exceptionally at that point. > So the main two questions are: > 1) Was the code intended to catch this UnsatisfiedLinkageError (I know Errors > are often considered a bad thing to catch) as a means to substitute the JNI > driver, incase it fails? > 2) If it is not supposed to catch this error, how can I use the pure Java > implementation in this case? I expect that trying to exclude relevant > packages also wont work as it will directly try to initiate the the JNI > implementation by its name, which would fail also with an Error. > So, in summary: > Is line 194 in class LevelDBFile in the camel-leveldb component supposed to > catch an Error or more generally a Throwable instead of Exception? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11623) LevelDB Java implementation wont be tried on Errors
[ https://issues.apache.org/jira/browse/CAMEL-11623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112400#comment-16112400 ] David J. M. Karlsen commented on CAMEL-11623: - Handling Throwable is usually not a good practice (would catch OutOfMemoryError for instance) - maybe better and clearer to narrow to multicatch of UnsatisfiedLinkageError | Exception ? > LevelDB Java implementation wont be tried on Errors > --- > > Key: CAMEL-11623 > URL: https://issues.apache.org/jira/browse/CAMEL-11623 > Project: Camel > Issue Type: Bug > Components: camel-leveldb >Affects Versions: 2.19.2 >Reporter: Mart Kartašev > Fix For: 2.18.5, 2.20.0, 2.19.3 > > > For a bit of background, we have been running into a problem with the LevelDB > JNI drivers for AggregationRepositories, which prevents startup when using > routes for which we require persistent aggregation. This, however, is not the > main topic of this issue. > In the latest version (2.19.2) the following issue has implemented a Java > specific leveldb factory: > https://issues.apache.org/jira/browse/CAMEL-11427 > The relevant part of the Error on startup is as follows: > java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no > leveldbjni64-1.8 in java.library.path, no leveldbjni-1.8 in > java.library.path, no leveldbjni in java.library.path, > C:\Users\atos\AppData\Local\Temp\leveldbjni-64-1-794362262645531032.8: Can't > find dependent libraries] > at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182) > at org.fusesource.hawtjni.runtime.Library.load(Library.java:140) > at org.fusesource.leveldbjni.JniDBFactory.(JniDBFactory.java:48) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at java.lang.Class.newInstance(Class.java:442) > at > org.apache.camel.component.leveldb.LevelDBFile.getFactory(LevelDBFile.java:189) > > at org.apache.camel.component.leveldb.LevelDBFile.start(LevelDBFile.java:174) > The way that I understand the code added in issue 11427, is that the > LevelDBFile class getFactory() method (line 181) will first try to initiate > with the JNI drivers and if that fails, will turn to the pure Java > implementation. This is done by catching an Exception which is then ignored > incase the JNI driver fails. > However, when we look at the code we see that UnstatisfiedLinkError does not > extend Exception, it extends Error. > This Error is therefore not caught by the application and thus the Java > implementation for LevelDB is never even attempted to be initialized as the > method execution ends exceptionally at that point. > So the main two questions are: > 1) Was the code intended to catch this UnsatisfiedLinkageError (I know Errors > are often considered a bad thing to catch) as a means to substitute the JNI > driver, incase it fails? > 2) If it is not supposed to catch this error, how can I use the pure Java > implementation in this case? I expect that trying to exclude relevant > packages also wont work as it will directly try to initiate the the JNI > implementation by its name, which would fail also with an Error. > So, in summary: > Is line 194 in class LevelDBFile in the camel-leveldb component supposed to > catch an Error or more generally a Throwable instead of Exception? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11422) Mark plugin as threadsafe
David J. M. Karlsen created CAMEL-11422:
---
Summary: Mark plugin as threadsafe
Key: CAMEL-11422
URL: https://issues.apache.org/jira/browse/CAMEL-11422
Project: Camel
Issue Type: Improvement
Affects Versions: 2.19.1
Reporter: David J. M. Karlsen
Priority: Minor
It would be nice to mark the camel maven plugin as threadsafe
{noformat}
22:00:20 [WARNING]
*
22:00:20 [WARNING] * Your build is requesting parallel execution, but project
*
22:00:20 [WARNING] * contains the following plugin(s) that have goals not
marked *
22:00:20 [WARNING] * as @threadSafe to support parallel building.
*
22:00:20 [WARNING] * While this /may/ work fine, please look for plugin updates
*
22:00:20 [WARNING] * and/or request plugins be made thread-safe.
*
22:00:20 [WARNING] * If reporting an issue, report it against the plugin in
*
22:00:20 [WARNING] * question, not against maven-core
*
22:00:20 [WARNING]
*
22:00:20 [WARNING] The following plugins are not marked @threadSafe in jfr-srv:
22:00:20 [WARNING] org.apache.camel:camel-maven-plugin:2.19.1
22:00:20 [WARNING] org.codehaus.mojo:tidy-maven-plugin:1.0.0
22:00:20 [WARNING] Enable debug to see more precisely which goals are not
marked @threadSafe.
22:00:20 [WARNING]
*
22:00:20 [INFO]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-10220) Support use of junit rules for spring test support
David J. M. Karlsen created CAMEL-10220: --- Summary: Support use of junit rules for spring test support Key: CAMEL-10220 URL: https://issues.apache.org/jira/browse/CAMEL-10220 Project: Camel Issue Type: New Feature Components: camel-spring, camel-test Reporter: David J. M. Karlsen It would be nice if the spring test support in camel-test-spring was realized as junit-rules instead of the runner so that runners can be freed for use with Parameterized etc. See http://blog.codeleak.pl/2015/08/parameterized-integration-tests-with.html http://docs.spring.io/spring-framework/docs/4.3.2.RELEASE/spring-framework-reference/htmlsingle/#testcontext-junit4-rules -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9821) camel-cxf should be able to handle InOnly MEP for the RAW|MESSAGE dataFormat
[ https://issues.apache.org/jira/browse/CAMEL-9821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237595#comment-15237595 ] David J. M. Karlsen commented on CAMEL-9821: Could https://issues.apache.org/jira/browse/CAMEL-9574 be fixed along this one? > camel-cxf should be able to handle InOnly MEP for the RAW|MESSAGE dataFormat > > > Key: CAMEL-9821 > URL: https://issues.apache.org/jira/browse/CAMEL-9821 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Reporter: Freeman Fang >Assignee: Freeman Fang > Fix For: 2.16.3, 2.17.1, 3.0.0 > > > In case when use MESSAGE|RAW dataFormat, which means don't read the > underlying InputStream so that can't determine the MEP(Message Exchange > Pattern) from the incoming message, so that need specify the mep explicitly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9837) Camel mail component documentation has BCC and CC options as upper-cased
[ https://issues.apache.org/jira/browse/CAMEL-9837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15230674#comment-15230674 ] David J. M. Karlsen commented on CAMEL-9837: I've fixed it on the wiki: https://cwiki.apache.org/confluence/display/CAMEL/Mail - should appear on the static site in a few hours. The issue can be closed. > Camel mail component documentation has BCC and CC options as upper-cased > > > Key: CAMEL-9837 > URL: https://issues.apache.org/jira/browse/CAMEL-9837 > Project: Camel > Issue Type: Bug >Affects Versions: 2.17.0 >Reporter: Tom Cunningham > > As of 2.17, it appears that "The Mail component now requires to configure to, > cc, and bcc using lower case keys, eg to=f...@bar.com, instead of > To=f...@bar.com as previously.".The Mail component documentation still > refers to these keys in upper case form : > http://camel.apache.org/mail.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9574) Be able to force one-way operation when using camel-cxf transport
David J. M. Karlsen created CAMEL-9574: -- Summary: Be able to force one-way operation when using camel-cxf transport Key: CAMEL-9574 URL: https://issues.apache.org/jira/browse/CAMEL-9574 Project: Camel Issue Type: New Feature Components: camel-cxf Reporter: David J. M. Karlsen It should be possible to make/force invocations oneway only (outonly? inonly?) either by setting the exchangePattern in the camel route or configuring the endpoint explicitly. The way it works today is that it will always wait synchronously for the response if invoking a request/reply defined operation. My usecase is to invoke soap webservices over JMS by using the camel cxf transport, but I would like the responses to appear decoupled on a dedicated messagedriven endpoint - not in a request/reply manner -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9095) Upgrade to spring 4.2.x
David J. M. Karlsen created CAMEL-9095: -- Summary: Upgrade to spring 4.2.x Key: CAMEL-9095 URL: https://issues.apache.org/jira/browse/CAMEL-9095 Project: Camel Issue Type: Wish Components: camel-spring, camel-spring-batch, camel-spring-boot, camel-spring-integration, camel-spring-javaconfig, camel-spring-redis, camel-spring-security, camel-spring-ws Reporter: David J. M. Karlsen Upgrade to latest spring release which is currently 4.2.0.RELEASE -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8667) java.lang.NullPointerException CamelSpringTestContextLoader.java:174
[
https://issues.apache.org/jira/browse/CAMEL-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693390#comment-14693390
]
David J. M. Karlsen commented on CAMEL-8667:
I fixed it in rev v.39 of that wiki page - wait a bit for the static site pages
to be generated and then I think this issue can be closed.
java.lang.NullPointerException CamelSpringTestContextLoader.java:174
Key: CAMEL-8667
URL: https://issues.apache.org/jira/browse/CAMEL-8667
Project: Camel
Issue Type: Bug
Components: camel-spring
Affects Versions: 2.15.1
Reporter: Chris Love
Assignee: Henryk Konsek
Fix For: 2.16.0, 2.15.3, 2.14.4
Attachments: DailyWeatherDataBeanUnmarshallTest.java
I am getting a NPE with camel spring unit testing. I am trying to convert
https://github.com/apache/camel/blob/master/components/camel-bindy/src/test/java/org/apache/camel/dataformat/bindy/fixed/unmarshall/simple/trim/BindySimpleFixedLengthUnmarshallTest.java
to pure annotations ... and I am getting a NPE ...
I am using:
{code:java}
@ContextConfiguration()
@RunWith(SpringJUnit4ClassRunner.class)
@BoostrapWith(CamelTestContextBootstrapper.class)
{code}
Here is my stack trace.
{code:java}
Caused by: java.lang.NullPointerException: null
at
org.apache.camel.test.spring.CamelSpringTestContextLoader.cleanup(CamelSpringTestContextLoader.java:174)
at
org.apache.camel.test.spring.CamelSpringTestContextLoader.loadContext(CamelSpringTestContextLoader.java:86)
at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:68)
at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:86)
at
org.springframework.test.context.DefaultTestContext.getApplicationContext(DefaultTestContext.java:72)
{code}
The unit test is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-4565) Allow to send messages using a user supplied pojo interface
[
https://issues.apache.org/jira/browse/CAMEL-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14623581#comment-14623581
]
David J. M. Karlsen commented on CAMEL-4565:
You can just add convertBodyTo and set the type to the type of the parameter
and it should work.
Allow to send messages using a user supplied pojo interface
---
Key: CAMEL-4565
URL: https://issues.apache.org/jira/browse/CAMEL-4565
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Christian Schneider
Assignee: Claus Ibsen
Fix For: 2.16.0
The basic requirement is that we want to send a user defined object to a
camel endpoint. The user code for sending the object should not contain any
camel code.
So imagine a simple DTO like Person with properties name and age. I would
like to use an interface like
interface PersonSender {
void send(Person person);
}
So in the use code I code get an implementation injected that I simply could
call with
sender.send(person);
So this is quite similar to our Pojo Messaging @Produce but I don´t want to
send a BeanInvocation. Instead I would like to just have the Person object in
the body. Ideally this should also support request / response if there is a
return type.
Additionally it should be configurable if it should send aynschronously or
synchronously.
Optionally we may also support a handler or Future for the response.
To get the interface implementation we should support up to three variants.
1) Create the dynamic proxy programmatically
2) Define the proxy thiough a spring bean
3) Create and inject the proxy using the @Produce annotation (we will need a
flag to switch behaviour or use a second annotation)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8593) JmsEndpoint.configureListenerContainer() some debug logs miss {}
[
https://issues.apache.org/jira/browse/CAMEL-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14394209#comment-14394209
]
David J. M. Karlsen commented on CAMEL-8593:
Don't see it on master?
https://github.com/apache/camel/blob/master/components/camel-jms/src/main/java/org/apache/camel/component/jms/JmsEndpoint.java
BTW: Had a pull-request for it: https://github.com/apache/camel/pull/461
JmsEndpoint.configureListenerContainer() some debug logs miss {}
Key: CAMEL-8593
URL: https://issues.apache.org/jira/browse/CAMEL-8593
Project: Camel
Issue Type: Improvement
Affects Versions: 2.13.3
Reporter: Martin Lichtin
Assignee: Willem Jiang
Priority: Trivial
Fix For: 2.14.3, 2.15.2, 2.16.0
In method JmsEndpoint.configureListenerContainer()
there are a few debug logs that miss the second {}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8429) batch consumer for camel-jms
David J. M. Karlsen created CAMEL-8429: -- Summary: batch consumer for camel-jms Key: CAMEL-8429 URL: https://issues.apache.org/jira/browse/CAMEL-8429 Project: Camel Issue Type: Improvement Components: camel-jms Reporter: David J. M. Karlsen I'm aware that the camel-sjms can do batch consumption, but it does not seem as mature and stable as camel-jms. It should be feasable to implement batch consumption for camel-jms by going along these lines: http://docs.spring.io/spring-batch/trunk/apidocs/org/springframework/batch/container/jms/BatchMessageListenerContainer.html http://sleeplessinslc.blogspot.no/2010/04/batchmessagelistenercontainer-using.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8293) Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl
[ https://issues.apache.org/jira/browse/CAMEL-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14301108#comment-14301108 ] David J. M. Karlsen commented on CAMEL-8293: It ran ok (mvn clean install -Pspring4 /tmp/build.log) until a test which fails due to something else: Test set: org.apache.camel.spring.processor.aggregator.SpringAggregateGroupedExchangeCompletionExpressionSizeTest --- Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.016 sec FAILURE! - in org.apache.camel.spring.processor.aggregator.SpringAggregateGroupedExchangeCompletionExpressionSizeTest testGrouped(org.apache.camel.spring.processor.aggregator.SpringAggregateGroupedExchangeCompletionExpressionSizeTest) Time elapsed: 0.015 sec ERROR! org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 28 in XML document from class path resource [org/apache/camel/spring/processor/aggregator/SpringAggregateGroupedExchangeCompletionExpressionSizeTest.xml] is invalid; nested exception is org.xml.sax.SAXParseException; lineNumber: 28; columnNumber: 46; cvc-complex-type.4: Attribute 'strategyRef' must appear on element 'aggregate'. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:203) Trying to rerun with -Dmaven.test.failure.ignore=true Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl -- Key: CAMEL-8293 URL: https://issues.apache.org/jira/browse/CAMEL-8293 Project: Camel Issue Type: Improvement Components: camel-test Affects Versions: 2.14.1 Reporter: David J. M. Karlsen CamelTestSupport has a protected JndiRegistry createRegistry() method. It would be better if it returned the Generic type Registry instead - that way you can override the method and return a SimpleRegistry for your tests without having to do this in createCamelContext() which defats createRegistry's purpose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8293) Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl
[ https://issues.apache.org/jira/browse/CAMEL-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen updated CAMEL-8293: --- Estimated Complexity: Novice (was: Unknown) Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl -- Key: CAMEL-8293 URL: https://issues.apache.org/jira/browse/CAMEL-8293 Project: Camel Issue Type: Improvement Components: camel-test Affects Versions: 2.14.1 Reporter: David J. M. Karlsen CamelTestSupport has a protected JndiRegistry createRegistry() method. It would be better if it returned the Generic type Registry instead - that way you can override the method and return a SimpleRegistry for your tests without having to do this in createCamelContext() which defats createRegistry's purpose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8293) Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl
David J. M. Karlsen created CAMEL-8293: -- Summary: Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl Key: CAMEL-8293 URL: https://issues.apache.org/jira/browse/CAMEL-8293 Project: Camel Issue Type: Improvement Components: camel-test Affects Versions: 2.14.1 Reporter: David J. M. Karlsen CamelTestSupport has a protected JndiRegistry createRegistry() method. It would be better if it returned the Generic type Registry instead - that way you can override the method and return a SimpleRegistry for your tests without having to do this in createCamelContext() which defats createRegistry's purpose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8293) Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl
[ https://issues.apache.org/jira/browse/CAMEL-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295934#comment-14295934 ] David J. M. Karlsen commented on CAMEL-8293: Pull request: https://github.com/apache/camel/pull/383 (Close it automatically by adding the text this closes #383 in the git comment. Be more override-friendly in CamelTestSupport by returning interface type instead of concrete impl -- Key: CAMEL-8293 URL: https://issues.apache.org/jira/browse/CAMEL-8293 Project: Camel Issue Type: Improvement Components: camel-test Affects Versions: 2.14.1 Reporter: David J. M. Karlsen CamelTestSupport has a protected JndiRegistry createRegistry() method. It would be better if it returned the Generic type Registry instead - that way you can override the method and return a SimpleRegistry for your tests without having to do this in createCamelContext() which defats createRegistry's purpose. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8236) WebSphere class loader detection is too sensitive
[ https://issues.apache.org/jira/browse/CAMEL-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275134#comment-14275134 ] David J. M. Karlsen commented on CAMEL-8236: com.ibm. is still very wide (looking at https://github.com/apache/camel/commit/91cc51ff0999e52ee284ab02ebfd768ac3f65c17) I suggest to go at least one package deeper. You can look at https://github.com/spring-projects/spring-framework/blob/master/spring-context/src/main/java/org/springframework/context/annotation/MBeanExportConfiguration.java to get some inspiration - but that is really about WAS management extensions. I downloaded some javadocs from: http://www-01.ibm.com/software/webservers/appserv/was/library/v85/nd-dp/ and maybe com.ibm.websphere.servlet.container. or com.ibm.websphere.servlet. is more suitable? WebSphere class loader detection is too sensitive - Key: CAMEL-8236 URL: https://issues.apache.org/jira/browse/CAMEL-8236 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Rafael Winterhalter Assignee: Willem Jiang Priority: Minor Fix For: 2.13.4, 2.14.2, 2.15.0 The DefaultCamelContext attempts to detect an IBM WebSphere application server by a simple test: loader.getClass().getName().startsWith(com.ibm) This test can introduce very subtle bugs when working with other IBM productes and I suggest to replace it by a list of known class names of WebSphere class loaders. At least, one should add an additional dot in order to avoid matching packages that only start with com.ibm such as any com.ibmfoobar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8236) WebSphere class loader detection is too sensitive
[ https://issues.apache.org/jira/browse/CAMEL-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275167#comment-14275167 ] David J. M. Karlsen commented on CAMEL-8236: I think in fact that too is too wide as webpshere is whole family of products and not only the app server. WebSphere class loader detection is too sensitive - Key: CAMEL-8236 URL: https://issues.apache.org/jira/browse/CAMEL-8236 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Rafael Winterhalter Assignee: Willem Jiang Priority: Minor Fix For: 2.13.4, 2.14.2, 2.15.0 The DefaultCamelContext attempts to detect an IBM WebSphere application server by a simple test: loader.getClass().getName().startsWith(com.ibm) This test can introduce very subtle bugs when working with other IBM productes and I suggest to replace it by a list of known class names of WebSphere class loaders. At least, one should add an additional dot in order to avoid matching packages that only start with com.ibm such as any com.ibmfoobar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8191) Charset is ignored for SFTP producer endpoints
[
https://issues.apache.org/jira/browse/CAMEL-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14263097#comment-14263097
]
David J. M. Karlsen commented on CAMEL-8191:
CAMEL-3787 seems to relate to filenames - not the encoding of the contents -
which I believe your issue is about? Or is it both?
Charset is ignored for SFTP producer endpoints
--
Key: CAMEL-8191
URL: https://issues.apache.org/jira/browse/CAMEL-8191
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 2.12.3, 2.14.1
Environment: vso@vso-desktop:/tmp$ uname -a
Linux vso-desktop 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9
12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
vso@vso-desktop:/tmp$ java -version
java version 1.7.0_65
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
vso@vso-desktop:/tmp$ ssh -v
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
Reporter: Volodymyr Sobotovych
Labels: charset, sftp
For SFTP producer endpoints option charset is ignored and the output file
is created using platform-default charset (usually UTF-8).
The simple Spring context illustrates the issue:
{code}
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd;
camelContext xmlns=http://camel.apache.org/schema/spring;
route
from uri=stream:in?promptMessage=Enter something: /
to
uri=sftp://localhost:22/vso/sandbox?charset=ISO-8859-1amp;username=fake_sftp_useramp;password=qwerty/
/route
/camelContext
/beans
{code}
This context defines a route that transfers the string entered by user via
SFTP. If the user enters Müller, I can see 7-byte message in the output
directory (because ü is represented using 2 bytes in UTF-8). While it
should be 6-byte message if the file was encoded in ISO-8859-1.
This problem affects only SFTP endpoints. File and FTP endpoints treat the
charset option correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8191) Charset is ignored for SFTP producer endpoints
[
https://issues.apache.org/jira/browse/CAMEL-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14261355#comment-14261355
]
David J. M. Karlsen commented on CAMEL-8191:
I don't think the endpoint actually supports the charset option - it's just
inherited by the more generic file component but not handled in the SFTP
component itself.
The conversion actually happens before the sftp component.
Have a look at https://gist.github.com/davidkarlsen/19cb1c8af7a8c5bd249e where
there are two alternative ways of solving this:
1) Giving the Exchange.CHARSET_NAME option (which will influence the converter)
or
2) converting to a byte array yourself and choosing the conversion charset
Charset is ignored for SFTP producer endpoints
--
Key: CAMEL-8191
URL: https://issues.apache.org/jira/browse/CAMEL-8191
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 2.12.3, 2.14.1
Environment: vso@vso-desktop:/tmp$ uname -a
Linux vso-desktop 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9
12:14:18 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
vso@vso-desktop:/tmp$ java -version
java version 1.7.0_65
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
vso@vso-desktop:/tmp$ ssh -v
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
Reporter: Volodymyr Sobotovych
Labels: charset, sftp
For SFTP producer endpoints option charset is ignored and the output file
is created using platform-default charset (usually UTF-8).
The simple Spring context illustrates the issue:
{code}
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd;
camelContext xmlns=http://camel.apache.org/schema/spring;
route
from uri=stream:in?promptMessage=Enter something: /
to
uri=sftp://localhost:22/vso/sandbox?charset=ISO-8859-1amp;username=fake_sftp_useramp;password=qwerty/
/route
/camelContext
/beans
{code}
This context defines a route that transfers the string entered by user via
SFTP. If the user enters Müller, I can see 7-byte message in the output
directory (because ü is represented using 2 bytes in UTF-8). While it
should be 6-byte message if the file was encoded in ISO-8859-1.
This problem affects only SFTP endpoints. File and FTP endpoints treat the
charset option correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8058) Use Java 7 api when possible
[ https://issues.apache.org/jira/browse/CAMEL-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216121#comment-14216121 ] David J. M. Karlsen commented on CAMEL-8058: AFAIK the system property has been there for some time (e.g. pre 1.7). But the method lineSeparator(): https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#lineSeparator-- is 1.7 Use Java 7 api when possible Key: CAMEL-8058 URL: https://issues.apache.org/jira/browse/CAMEL-8058 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.15.0 Reporter: Claus Ibsen Priority: Minor We have some custom code that figures out the line terminator. But since Java 1.7 we can use System.getProperty(line.separator) There may be a few other spots with some code that can be replaced with apis from java7 onwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7901) org.apache.camel.component.mock.MockEndpoint expectedBodiesReceived fails with but was: null message
[
https://issues.apache.org/jira/browse/CAMEL-7901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14166554#comment-14166554
]
David J. M. Karlsen commented on CAMEL-7901:
Move mep.expectedBodiesReceived(test body) before sendBody and it should work.
org.apache.camel.component.mock.MockEndpoint expectedBodiesReceived fails
with but was: null message
Key: CAMEL-7901
URL: https://issues.apache.org/jira/browse/CAMEL-7901
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.0
Environment: scala 2.10.3
camel 2.13.0
akka 2.3.1
OSX 10.8.5
Intellij IDEA 13.0.2
Reporter: Robert Courtney
Labels: patch
A small scala + akka + camel test seems to show that the
MockEndpoint.expectedBodiesReceived(final List? bodies) method is not
working as expected.
the following scala code excerpt:
val mep =
camelContext.getEndpoint(mock:file).asInstanceOf[MockEndpoint]
camel.template.sendBody(mep, test body)
println(all exchanges:)
val exchanges = mep.getReceivedExchanges
println(exchanges)
// mep.expectedMessageCount(1) // WORKS
mep.expectedBodiesReceived(test body) // FAILS
mep.assertIsSatisfied
fails with this output:
2014-10-10 16:41:58,692 DEBUG o.a.c.component.mock.MockEndpoint -
mock://file 0 : Exchange[Message: test body] with body: test body and
headers:{breadcrumbId=ID-nbns-MacBook-Pro-local-59447-1412919718220-0-1}
all exchanges:
[Exchange[Message: test body]]
2014-10-10 16:41:58,693 INFO o.a.c.component.mock.MockEndpoint - Asserting:
Endpoint[mock://file] is satisfied
2014-10-10 16:41:58,694 DEBUG o.a.c.component.mock.MockEndpoint -
mock://file failed and received[1]: Exchange[Message: test body]
mock://file Body of message: 0. Expected: test body but was: null
java.lang.AssertionError: mock://file Body of message: 0. Expected: test
body but was: null
at
org.apache.camel.component.mock.MockEndpoint.fail(MockEndpoint.java:1333)
at
org.apache.camel.component.mock.MockEndpoint.assertEquals(MockEndpoint.java:1315)
at
org.apache.camel.component.mock.MockEndpoint$5.run(MockEndpoint.java:628)
at
org.apache.camel.component.mock.MockEndpoint.doAssertIsSatisfied(MockEndpoint.java:394)
at
org.apache.camel.component.mock.MockEndpoint.assertIsSatisfied(MockEndpoint.java:362)
at
org.apache.camel.component.mock.MockEndpoint.assertIsSatisfied(MockEndpoint.java:350)
It looks like the problem is in MockEndpoint.java (line 613), where the
actualBodyValues variable is initialised to an empty ArrayList on each
invocation of expectedBodiesReceived(...), wiping out any values which were
added to this List at line 1220 in performAssertions()
I've looked through the same code in camel-core 2.13.x and 2.14 and the same
code exists there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7868) wrong concatenation of parameters in JettyHttpComponent
David J. M. Karlsen created CAMEL-7868: -- Summary: wrong concatenation of parameters in JettyHttpComponent Key: CAMEL-7868 URL: https://issues.apache.org/jira/browse/CAMEL-7868 Project: Camel Issue Type: Bug Components: camel-jetty Reporter: David J. M. Karlsen See http://camel.465427.n5.nabble.com/bug-restConfiguration-jetty-endpointProperty-td5757065.html for details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7874) regression: cannot set property prettyPrint on json dataformat any longer
David J. M. Karlsen created CAMEL-7874: -- Summary: regression: cannot set property prettyPrint on json dataformat any longer Key: CAMEL-7874 URL: https://issues.apache.org/jira/browse/CAMEL-7874 Project: Camel Issue Type: Bug Components: camel-jackson Affects Versions: 2.14.0 Environment: Jackson Reporter: David J. M. Karlsen Priority: Minor See http://camel.465427.n5.nabble.com/Problems-prettyPrinting-JSON-after-camel-2-14-0-upgrade-td5756738.html#a5757104 for a background. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7733) Sending a CamelCacheDeleteAll does not actually delete anything
[ https://issues.apache.org/jira/browse/CAMEL-7733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106522#comment-14106522 ] David J. M. Karlsen commented on CAMEL-7733: When would you expect the cache-backing file to change? AFAIK it will not happen immediately/synchronously, but when worker thread wakes or cache is shutdown: http://whatdidilearn2day.blogspot.no/2009/09/semantics-of-flushing-in-ehcache.html . Do you call shutdown on the cache when your app/service terminates? Sending a CamelCacheDeleteAll does not actually delete anything --- Key: CAMEL-7733 URL: https://issues.apache.org/jira/browse/CAMEL-7733 Project: Camel Issue Type: Bug Components: camel-cache Affects Versions: 2.13.2 Environment: Karaf 3.0.1, CentOS 6 Reporter: Matt Sicker Priority: Minor Sending a CamelCacheOperation of CamelCacheDeleteAll doesn't actually delete anything from the cache. It might be clearing out the in-memory cache, but anything that's persisted to disk won't be cleared. This causes immense problems anytime a stray class gets serialized that had its serialization format updated. Constant exceptions from attempting to get items from the cache is not what should be happening here. If I delete the cache file EHCache is using, that obviously does nothing as it still has a file handle on it and will continue using it unless I completely restart Karaf. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7732) Can't supply beanRowMapper option to JDBC URI
[ https://issues.apache.org/jira/browse/CAMEL-7732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105611#comment-14105611 ] David J. M. Karlsen commented on CAMEL-7732: try this instead: beanRowMapper=#nameOfSpringBean Can't supply beanRowMapper option to JDBC URI - Key: CAMEL-7732 URL: https://issues.apache.org/jira/browse/CAMEL-7732 Project: Camel Issue Type: Bug Components: camel-jdbc Affects Versions: 2.13.2 Reporter: Nathan Wray When trying to override the DefaultBeanRowMapper with a custom mapper on a jdbc using the beanRowMapper option in the URI, such as: jdbc:MyDS?useHeadersAsParameters=trueamp;outputType=SelectOneamp;outputClass=com.foo.Baramp;beanRowMapper=com.my.CorrectedBeanRowMapper The following error is thrown, complaining that it doesn't know how to turn a string into an instance of BeanRowMapper: Caused By: java.lang.IllegalArgumentException: Could not find a suitable setter for property: beanRowMapper as there isn't a setter method with same type: java.lang.String nor type conversion possible: No type converter available to convert from type: java.lang.String to the required type: org.apache.camel.component.jdbc.BeanRowMapper with value com.my.CorrectedBeanRowMapper -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7504) Improve the throttler to have discarding/filtering capabilities
[
https://issues.apache.org/jira/browse/CAMEL-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14041218#comment-14041218
]
David J. M. Karlsen commented on CAMEL-7504:
Works like a charm!:
{noformat}
2014-06-23 21:49:15,467 [Camel (camel-1) thread #0 -
timer://myTimer][][][][][][][] ERROR
org.apache.camel.processor.FatalFallbackErrorHandler:54 - \-- Previous
exception on exchangeId: ID-aap-prx-01-34540-140300
3938060-0-366007
java.util.concurrent.RejectedExecutionException: Exceed the max request limit!
at
org.apache.camel.processor.Throttler.processDelay(Throttler.java:215)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.DelayProcessorSupport.process(DelayProcessorSupport.java:168)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:105)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:40)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
com.davidkarlsen.httptest.MyRouteBuilder$2.process(MyRouteBuilder.java:113)
~[http-test-1.0-SNAPSHOT.jar:na]
at
org.apache.camel.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:63)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.FatalFallbackErrorHandler.process(FatalFallbackErrorHandler.java:42)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.RedeliveryErrorHandler.deliverToFailureProcessor(RedeliveryErrorHandler.java:839)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:337)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:157)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:68)
[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at java.util.Timer$TimerImpl.run(Timer.java:291) [na:na]
2014-06-23 21:49:15,470 [Camel (camel-1) thread #0 -
timer://myTimer][][][][][][][] ERROR
org.apache.camel.processor.FatalFallbackErrorHandler:55 - \-- New exception on
exchangeId: ID-aap-prx-01-34540-14030039380
60-0-366007
java.util.concurrent.RejectedExecutionException: Exceed the max request limit!
at
org.apache.camel.processor.Throttler.processDelay(Throttler.java:215)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
org.apache.camel.processor.DelayProcessorSupport.process(DelayProcessorSupport.java:168)
~[camel-core-2.14-20140617.030729-34.jar:2.14-SNAPSHOT]
at
[jira] [Commented] (CAMEL-7504) Improve the throttler to have discarding/filtering capabilities
[ https://issues.apache.org/jira/browse/CAMEL-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14035518#comment-14035518 ] David J. M. Karlsen commented on CAMEL-7504: Upgraded one of my production instances. Need to wait until the route gets some traffic to see if it works. Improve the throttler to have discarding/filtering capabilities --- Key: CAMEL-7504 URL: https://issues.apache.org/jira/browse/CAMEL-7504 Project: Camel Issue Type: Improvement Components: camel-core Reporter: David J. M. Karlsen Assignee: Willem Jiang It would be nice if the throttler, http://camel.apache.org/throttler.html, could discard/filter the messages exceeding the limit. My usecase is to send alerts to a alering route, and stick the trottler in front of an smtp endpoint to limit the number of emails sent during a period. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7504) Improve the throttler to have discarding/filtering capabilities
David J. M. Karlsen created CAMEL-7504: -- Summary: Improve the throttler to have discarding/filtering capabilities Key: CAMEL-7504 URL: https://issues.apache.org/jira/browse/CAMEL-7504 Project: Camel Issue Type: Improvement Components: camel-core Reporter: David J. M. Karlsen Priority: Critical It would be nice if the throttler, http://camel.apache.org/throttler.html, could discard/filter the messages exceeding the limit. My usecase is to send alerts to a alering route, and stick the trottler in front of an smtp endpoint to limit the number of emails sent during a period. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7505) Explain the use of the UUID generator
David J. M. Karlsen created CAMEL-7505: -- Summary: Explain the use of the UUID generator Key: CAMEL-7505 URL: https://issues.apache.org/jira/browse/CAMEL-7505 Project: Camel Issue Type: Improvement Components: documentation Reporter: David J. M. Karlsen http://camel.apache.org/uuidgenerator.html mentions the different UUID generators which can be set on a context - but does not mention what it´s used for. Does an ID always be generated for an exchange? Will it be set as a header? Can I as an user interact with it and get id´s generated? etc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7461) Idempotent inconsistensies / idempotent consumer should allow for messageId of any type
David J. M. Karlsen created CAMEL-7461: -- Summary: Idempotent inconsistensies / idempotent consumer should allow for messageId of any type Key: CAMEL-7461 URL: https://issues.apache.org/jira/browse/CAMEL-7461 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.13.1 Reporter: David J. M. Karlsen Priority: Minor See http://camel.465427.n5.nabble.com/Idempotent-inconsistencies-td5751484.html for a background. Basically there is inconsistency between a idempotent consumer and the repository. The repository is capable of holding any type, while the consumer is non-parameterized and uses String as it's message type. It would be very handy to have the messageid as a domain type for any application, and thus the consumer should allow for a parameterized type T. This will also probably mean that JpaMessageIdRepository should allow for any persistent type. If doing this camel would be generic on the type, and allow for supporting application domain types w/o customizations. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7074) Upgrade to spring 4.x
[
https://issues.apache.org/jira/browse/CAMEL-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984072#comment-13984072
]
David J. M. Karlsen commented on CAMEL-7074:
cxf 3.0 shouldn't be far away now:
http://cxf.547215.n5.nabble.com/When-Will-3-0-Officially-Release-td5743388.html
Upgrade to spring 4.x
-
Key: CAMEL-7074
URL: https://issues.apache.org/jira/browse/CAMEL-7074
Project: Camel
Issue Type: Task
Components: camel-spring
Reporter: David J. M. Karlsen
Assignee: Willem Jiang
Fix For: 2.14.0
Upgrade to spring4.
There is a non-backwards compatible change in spring 4.x which will cause:
{noformat}
java.lang.IncompatibleClassChangeError: Found interface
org.springframework.test.context.TestContext, but class was expected
at
org.apache.camel.test.spring.CamelSpringTestContextLoaderTestExecutionListener.prepareTestInstance(CamelSpringTestContextLoaderTestExecutionListener.java:35)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:326)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:212)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:232)
at
org.apache.camel.test.junit4.CamelSpringJUnit4ClassRunner.runChild(CamelSpringJUnit4ClassRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:175)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:
{noformat}
due to https://jira.springsource.org/browse/SPR-7692
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7374) Slow message processing due to unnecessary logging
[
https://issues.apache.org/jira/browse/CAMEL-7374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13971807#comment-13971807
]
David J. M. Karlsen commented on CAMEL-7374:
afaik camel uses slf4j which will not call toString unless it is neccessary:
http://www.slf4j.org/faq.html#logging_performance
Slow message processing due to unnecessary logging
--
Key: CAMEL-7374
URL: https://issues.apache.org/jira/browse/CAMEL-7374
Project: Camel
Issue Type: Bug
Components: camel-core, camel-jms
Affects Versions: 2.12.1
Environment: Windows 7 Enterprise 64 bit, Oracle JRE 1.7.0.51
Reporter: Martin Marinov
Attachments: hotspot_bad.JPG
org.apache.camel.component.jms.EndpointMessageListener.onMessage, line 68:
LOG.debug({} consumer received JMS message: {}, endpoint, message);
When debug logging is disabled, the log string from above will not be output
anywhere. Nevertheless, it will still be generated. The problem is that
DefaultEndpoint.toString() calls URISupport.sanitizeUri() which uses regex
pattern matching and replacing to process the passed endpoint URL. The
java.util.regex.Matcher.replaceFirst methods turned out to be rather time
consuming, thus slowing down the message processing and decreasing the
message throughput under high loads.
The same problem is observed in
org.apache.camel.processor.SendProcessor.process(). It causes slower sending.
Commenting the LOG.debug invocations at these places improved the message
throughput almost 3 times! The solution, of course is not comment these
lines, but probably to put them inside
if (LOG.isDebugEnabled()) { } blocks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-6707) Asynchronous Mode In camel-servlet, Servlet 3.0 AsyncContext
[ https://issues.apache.org/jira/browse/CAMEL-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920694#comment-13920694 ] David J. M. Karlsen commented on CAMEL-6707: Any update on this? We´re in the same situation and have to create our own custom servlet to accommodate async processing. Asynchronous Mode In camel-servlet, Servlet 3.0 AsyncContext Key: CAMEL-6707 URL: https://issues.apache.org/jira/browse/CAMEL-6707 Project: Camel Issue Type: Improvement Components: camel-http, camel-servlet Affects Versions: 2.13.0 Reporter: Jörg Schubert Priority: Minor My Goal is routing larger amounts of HTTP-Traffic CamelServlet is blocking the HTTP-thread while message is being processed. I'm currently preparing a patch which uses AsyncContext and starts processor in async mode. Hope that will improve throughput. The async feature is switchable by parameter. I will attach a patch as soon as it works. There is one point: To avoid conflicts geronimo-servlet_2.5_spec must be replaced by geronimo-servlet_3.0_spec in parent pom. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-6707) Asynchronous Mode In camel-servlet, Servlet 3.0 AsyncContext
[ https://issues.apache.org/jira/browse/CAMEL-6707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13920763#comment-13920763 ] David J. M. Karlsen commented on CAMEL-6707: And here is another user with the same request: http://camel.465427.n5.nabble.com/Camel-Users-f465428i70.html Asynchronous Mode In camel-servlet, Servlet 3.0 AsyncContext Key: CAMEL-6707 URL: https://issues.apache.org/jira/browse/CAMEL-6707 Project: Camel Issue Type: Improvement Components: camel-http, camel-servlet Affects Versions: 2.13.0 Reporter: Jörg Schubert Priority: Minor My Goal is routing larger amounts of HTTP-Traffic CamelServlet is blocking the HTTP-thread while message is being processed. I'm currently preparing a patch which uses AsyncContext and starts processor in async mode. Hope that will improve throughput. The async feature is switchable by parameter. I will attach a patch as soon as it works. There is one point: To avoid conflicts geronimo-servlet_2.5_spec must be replaced by geronimo-servlet_3.0_spec in parent pom. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7074) Upgrade to spring 4.x
[
https://issues.apache.org/jira/browse/CAMEL-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13903867#comment-13903867
]
David J. M. Karlsen commented on CAMEL-7074:
You can also monitor this job:
https://builds.apache.org/job/Camel.trunk.fulltest.spring4/ . Guess cxf 3 is
the last major step to get it to pass.
Upgrade to spring 4.x
-
Key: CAMEL-7074
URL: https://issues.apache.org/jira/browse/CAMEL-7074
Project: Camel
Issue Type: Task
Components: camel-spring
Reporter: David J. M. Karlsen
Assignee: Willem Jiang
Fix For: Future
Upgrade to spring4.
There is a non-backwards compatible change in spring 4.x which will cause:
{noformat}
java.lang.IncompatibleClassChangeError: Found interface
org.springframework.test.context.TestContext, but class was expected
at
org.apache.camel.test.spring.CamelSpringTestContextLoaderTestExecutionListener.prepareTestInstance(CamelSpringTestContextLoaderTestExecutionListener.java:35)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:326)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:212)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:232)
at
org.apache.camel.test.junit4.CamelSpringJUnit4ClassRunner.runChild(CamelSpringJUnit4ClassRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:175)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:
{noformat}
due to https://jira.springsource.org/browse/SPR-7692
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CAMEL-7074) Upgrade to spring 4.x
[
https://issues.apache.org/jira/browse/CAMEL-7074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13850248#comment-13850248
]
David J. M. Karlsen commented on CAMEL-7074:
[~njiang]: exactly - and that's why I created the issue, wondering what version
of camel this would be done for.
Upgrade to spring 4.x
-
Key: CAMEL-7074
URL: https://issues.apache.org/jira/browse/CAMEL-7074
Project: Camel
Issue Type: Task
Components: camel-spring
Reporter: David J. M. Karlsen
Assignee: Willem Jiang
Upgrade to spring4.
There is a non-backwards compatible change in spring 4.x which will cause:
{noformat}
java.lang.IncompatibleClassChangeError: Found interface
org.springframework.test.context.TestContext, but class was expected
at
org.apache.camel.test.spring.CamelSpringTestContextLoaderTestExecutionListener.prepareTestInstance(CamelSpringTestContextLoaderTestExecutionListener.java:35)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:326)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:212)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:232)
at
org.apache.camel.test.junit4.CamelSpringJUnit4ClassRunner.runChild(CamelSpringJUnit4ClassRunner.java:37)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:175)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:
{noformat}
due to https://jira.springsource.org/browse/SPR-7692
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CAMEL-5539) Circuit Breaker EIP
[ https://issues.apache.org/jira/browse/CAMEL-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13743662#comment-13743662 ] David J. M. Karlsen commented on CAMEL-5539: Some additional resources: https://code.google.com/p/kite-lib/wiki/CircuitBreaker http://dev.hubspot.com/blog/bid/64543/Building-a-Robust-System-Using-the-Circuit-Breaker-Pattern http://www.amazon.com/Release-It-Production-Ready-Pragmatic-Programmers/dp/0978739213 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: Raul Kripalani Fix For: Future 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6626) Search critera for toSentDate throws NPE
[
https://issues.apache.org/jira/browse/CAMEL-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736900#comment-13736900
]
David J. M. Karlsen commented on CAMEL-6626:
https://github.com/apache/camel/pull/39
Search critera for toSentDate throws NPE
Key: CAMEL-6626
URL: https://issues.apache.org/jira/browse/CAMEL-6626
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.11.1
Reporter: Ales Dolecek
Labels: easyfix
Fix For: 2.11.2, 2.12.0
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Use of searchTerm.toSentDate=now-24h (to poll only mails older than 24 hours)
throws NPE. This is because MailConverters#toSearchTerm tries to build
toSentDate criteria from fromSentDate value:
if (simple.getToSentDate() != null) {
String s = simple.getFromSentDate();
if (s.startsWith(now)) {
The middle line should be:
String s = simple.getToSentDate();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6626) Search critera for toSentDate throws NPE
[
https://issues.apache.org/jira/browse/CAMEL-6626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737168#comment-13737168
]
David J. M. Karlsen commented on CAMEL-6626:
I've updated the branch.
Search critera for toSentDate throws NPE
Key: CAMEL-6626
URL: https://issues.apache.org/jira/browse/CAMEL-6626
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.11.1
Reporter: Ales Dolecek
Labels: easyfix
Fix For: 2.11.2, 2.12.0
Original Estimate: 0.5h
Remaining Estimate: 0.5h
Use of searchTerm.toSentDate=now-24h (to poll only mails older than 24 hours)
throws NPE. This is because MailConverters#toSearchTerm tries to build
toSentDate criteria from fromSentDate value:
if (simple.getToSentDate() != null) {
String s = simple.getFromSentDate();
if (s.startsWith(now)) {
The middle line should be:
String s = simple.getToSentDate();
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6603) Long - Date TypeConverter
David J. M. Karlsen created CAMEL-6603: -- Summary: Long - Date TypeConverter Key: CAMEL-6603 URL: https://issues.apache.org/jira/browse/CAMEL-6603 Project: Camel Issue Type: New Feature Components: camel-core Reporter: David J. M. Karlsen http://camel.465427.n5.nabble.com/Long-lt-gt-Date-TypeConverter-td5736428.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6587) Cannot build camel with maven 3.1
[
https://issues.apache.org/jira/browse/CAMEL-6587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13724479#comment-13724479
]
David J. M. Karlsen commented on CAMEL-6587:
Yes - this is what I have in the pull request:
https://github.com/davidkarlsen/camel/tree/CAMEL-6587
Cannot build camel with maven 3.1
-
Key: CAMEL-6587
URL: https://issues.apache.org/jira/browse/CAMEL-6587
Project: Camel
Issue Type: Task
Components: build system
Reporter: David J. M. Karlsen
Assignee: Christian Müller
Priority: Minor
Attempting to build master with maven 3.1.0 fails with:
{noformat}
[INFO] Final Memory: 175M/419M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.0:shade (default) on project
camel-core: Execution default of goal
org.apache.maven.plugins:maven-shade-plugin:2.0:shade failed: A required
class was missing while executing
org.apache.maven.plugins:maven-shade-plugin:2.0:shade:
org/sonatype/aether/version/VersionConstraint
[ERROR] -
[ERROR] realm =pluginorg.apache.maven.plugins:maven-shade-plugin:2.0
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
[ERROR] urls[0] =
file:/home/et2448/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/2.0/maven-shade-plugin-2.0.jar
[ERROR] urls[1] =
file:/home/et2448/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
[ERROR] urls[2] =
file:/home/et2448/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
[ERROR] urls[3] =
file:/home/et2448/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
[ERROR] urls[4] =
file:/home/et2448/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
[ERROR] urls[5] =
file:/home/et2448/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
[ERROR] urls[6] =
file:/home/et2448/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
[ERROR] urls[7] =
file:/home/et2448/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
[ERROR] urls[8] =
file:/home/et2448/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
[ERROR] urls[9] =
file:/home/et2448/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.1/plexus-utils-3.0.1.jar
[ERROR] urls[10] =
file:/home/et2448/.m2/repository/asm/asm/3.3.1/asm-3.3.1.jar
[ERROR] urls[11] =
file:/home/et2448/.m2/repository/asm/asm-commons/3.3.1/asm-commons-3.3.1.jar
[ERROR] urls[12] =
file:/home/et2448/.m2/repository/asm/asm-tree/3.3.1/asm-tree-3.3.1.jar
[ERROR] urls[13] =
file:/home/et2448/.m2/repository/org/jdom/jdom/1.1/jdom-1.1.jar
[ERROR] urls[14] =
file:/home/et2448/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.0/maven-dependency-tree-2.0.jar
[ERROR] urls[15] =
file:/home/et2448/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
[ERROR] urls[16] =
file:/home/et2448/.m2/repository/org/vafer/jdependency/0.7/jdependency-0.7.jar
[ERROR] urls[17] =
file:/home/et2448/.m2/repository/commons-io/commons-io/1.3.2/commons-io-1.3.2.jar
[ERROR] urls[18] =
file:/home/et2448/.m2/repository/asm/asm-analysis/3.2/asm-analysis-3.2.jar
[ERROR] urls[19] =
file:/home/et2448/.m2/repository/asm/asm-util/3.2/asm-util-3.2.jar
[ERROR] Number of foreign imports: 1
[ERROR] import: Entry[import from realm
ClassRealm[projectorg.apache.camel:camel-parent:2.12-SNAPSHOT, parent:
ClassRealm[maven.api, parent: null]]]
[ERROR]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6567) Upgrade to Spring Batch 2.2.0
[ https://issues.apache.org/jira/browse/CAMEL-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13719528#comment-13719528 ] David J. M. Karlsen commented on CAMEL-6567: I created this issue in spring batch - let's see what they respond: https://jira.springsource.org/browse/BATCH-2069 Upgrade to Spring Batch 2.2.0 - Key: CAMEL-6567 URL: https://issues.apache.org/jira/browse/CAMEL-6567 Project: Camel Issue Type: Task Components: camel-spring-batch Reporter: David J. M. Karlsen Assignee: Willem Jiang Priority: Minor Fix For: 2.12.0 Upgrade to spring batch 2.2.0RELEASE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6567) Upgrade to Spring Batch 2.2.0
David J. M. Karlsen created CAMEL-6567: -- Summary: Upgrade to Spring Batch 2.2.0 Key: CAMEL-6567 URL: https://issues.apache.org/jira/browse/CAMEL-6567 Project: Camel Issue Type: New Feature Components: camel-spring-batch Reporter: David J. M. Karlsen Fix For: 2.12.0 Upgrade to spring batch 2.2.0RELEASE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6567) Upgrade to Spring Batch 2.2.0
[ https://issues.apache.org/jira/browse/CAMEL-6567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13715146#comment-13715146 ] David J. M. Karlsen commented on CAMEL-6567: Can be fetched from https://github.com/davidkarlsen/camel/tree/CAMEL-6567 Upgrade to Spring Batch 2.2.0 - Key: CAMEL-6567 URL: https://issues.apache.org/jira/browse/CAMEL-6567 Project: Camel Issue Type: New Feature Components: camel-spring-batch Reporter: David J. M. Karlsen Fix For: 2.12.0 Upgrade to spring batch 2.2.0RELEASE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6539) Typeconverter for Spring Resource abstraction
David J. M. Karlsen created CAMEL-6539: -- Summary: Typeconverter for Spring Resource abstraction Key: CAMEL-6539 URL: https://issues.apache.org/jira/browse/CAMEL-6539 Project: Camel Issue Type: Bug Components: camel-spring Reporter: David J. M. Karlsen Priority: Trivial I have code and test in https://github.com/davidkarlsen/camel/tree/springResourceConverter forked off master. Pull request: https://github.com/apache/camel/pull/29 as patch: https://github.com/apache/camel/pull/29.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6476) StreamCachingStrategy - A better strategy
[ https://issues.apache.org/jira/browse/CAMEL-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13690365#comment-13690365 ] David J. M. Karlsen commented on CAMEL-6476: I guess having a configurable threshold value for when to spool would be the best. And to expose this in the DSL when activating streaming for a context. StreamCachingStrategy - A better strategy - Key: CAMEL-6476 URL: https://issues.apache.org/jira/browse/CAMEL-6476 Project: Camel Issue Type: New Feature Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.12.0 The old stream caching has some flaws such as - copying the existing stream into an internal buffer/type - spool to disk by default - a bit confusing to configure - wrap based - not exposed in JMX - not easy to implement custom strategies Working on a new strategy that supports - reusing existing stream if it supports marks - memory based only by default - threshold for spooling to disk based on memory usage, and payload sizes - use the internal camel processor to avoid wrapping - exposed in JMX with runtime stats - only enabled if explicit turned on - log at INFO level on startup if enabled and what settings is in use - configuring in the DSL with a xxxDefinition to make it stand out in the XML DSLs -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
[
https://issues.apache.org/jira/browse/CAMEL-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13678082#comment-13678082
]
David J. M. Karlsen commented on CAMEL-6317:
Ping? The testcase I refer in my git repo could be incorporated into camel?
Camel-validator not able to resolve schema when using useSharedSchema=false
---
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
Assignee: Claus Ibsen
Fix For: 2.11.1
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
it fails with:
{noformat}
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema
document 'null', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not xsd:schema.
{noformat}
The streamsource object in the validator is populated, but the buffered
inputstream object has no content
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
[
https://issues.apache.org/jira/browse/CAMEL-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13645531#comment-13645531
]
David J. M. Karlsen commented on CAMEL-6317:
I have a reproducable case in: g...@github.com:davidkarlsen/camel6317.git,
which fails consistently on the following 4 different JDKs (all latest version)
- and the case failing is actually the one to avoid the JDK bug:
et2448@ubuntu:~/projects/ext/github.com/camel-6317$ /opt/jdk1.7/bin/java
-version
java version 1.7.0_21
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
et2448@ubuntu:~/projects/ext/github.com/camel-6317$ /opt/jdk1.6/bin/java
-version
java version 1.6.0_45
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
et2448@ubuntu:~/projects/ext/github.com/camel-6317$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
et2448@ubuntu:~/projects/ext/github.com/camel-6317$
/opt/ibm/ibm-java-i386-70/bin/java -version
java version 1.7.0
Java(TM) SE Runtime Environment (build pxi3270sr4fp1-20130325_01(SR4 FP1))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20130306_140761 (JIT enabled, AOT
enabled)
J9VM - R26_Java726_SR4_FP1_20130306_1011_B140761
JIT - r11.b03_20130131_32403ifx1
GC - R26_Java726_SR4_FP1_20130306_1011_B140761
J9CL - 20130306_140761)
JCL - 20130315_01 based on Oracle 7u13-b08
Camel-validator not able to resolve schema when using useSharedSchema=false
---
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
Assignee: Claus Ibsen
Fix For: 2.11.1
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
it fails with:
{noformat}
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema
document 'null', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not xsd:schema.
{noformat}
The streamsource object in the validator is populated, but the buffered
inputstream object has no content
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
[
https://issues.apache.org/jira/browse/CAMEL-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated CAMEL-6317:
---
Component/s: (was: camel-core)
camel-validator
Camel-validator not able to resolve schema when using useSharedSchema=false
---
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5860) Regression in validator component in 2.10.3
[
https://issues.apache.org/jira/browse/CAMEL-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated CAMEL-5860:
---
Component/s: (was: camel-core)
camel-validator
Regression in validator component in 2.10.3
---
Key: CAMEL-5860
URL: https://issues.apache.org/jira/browse/CAMEL-5860
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.10.3
Environment: schema on classpath in src/main/resources
Reporter: David J. M. Karlsen
Assignee: Willem Jiang
Fix For: 2.9.6, 2.10.4, 2.11.0
I get:
{code}
CaughtExceptionType:java.lang.NullPointerException,
CaughtExceptionMessage:null, StackTrace:java.lang.NullPointerException at
org.apache.camel.converter.jaxp.XmlConverter.toStreamSource(XmlConverter.java:516)
at
org.apache.camel.converter.jaxp.XmlConverter.toSAXSource(XmlConverter.java:399)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.lang.reflect.Method.invoke(Method.java:601) at
org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:923)
at
org.apache.camel.impl.converter.InstanceMethodTypeConverter.convertTo(InstanceMethodTypeConverter.java:66)
at
org.apache.camel.support.TypeConverterSupport.convertTo(TypeConverterSupport.java:34)
at
org.apache.camel.processor.validation.ValidatingProcessor.getSource(ValidatingProcessor.java:343)
at
org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:100)
at
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
at
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
\
{code}
when I upgrade camel to 2.10.3 and use the validator component:
{noformat}
camel:to uri=validator:META-INF/xsd/transactiongatetransfertransaction.xsd
/
{noformat}
this did not happen in 2.10.2 or versions before that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
[
https://issues.apache.org/jira/browse/CAMEL-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated CAMEL-6317:
---
Description:
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
it fails with:
{noformat}
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema
document 'null', because 1) could not find the document; 2) the document could
not be read; 3) the root element of the document is not xsd:schema.
{noformat}
The streamsource object in the validator is populated, but the buffered
inputstream object has no content
was:
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
Camel-validator not able to resolve schema when using useSharedSchema=false
---
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
it fails with:
{noformat}
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema
document 'null', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not xsd:schema.
{noformat}
The streamsource object in the validator is populated, but the buffered
inputstream object has no content
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
[
https://issues.apache.org/jira/browse/CAMEL-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642708#comment-13642708
]
David J. M. Karlsen edited comment on CAMEL-6317 at 4/26/13 9:39 AM:
-
Doh - forgot to add the exception - edited in now.
This test is a unit-test running in eclipse. I usually run the app in
spring/jetty.
was (Author: davidkarl...@gmail.com):
Doh - forgot to add the exception - edited in now.
This test is a unit-test running in eclipse. I usually run the app in jetty.
Camel-validator not able to resolve schema when using useSharedSchema=false
---
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
it fails with:
{noformat}
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema
document 'null', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not xsd:schema.
{noformat}
The streamsource object in the validator is populated, but the buffered
inputstream object has no content
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
[
https://issues.apache.org/jira/browse/CAMEL-6317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642708#comment-13642708
]
David J. M. Karlsen commented on CAMEL-6317:
Doh - forgot to add the exception - edited in now.
This test is a unit-test running in eclipse. I usually run the app in jetty.
Camel-validator not able to resolve schema when using useSharedSchema=false
---
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-validator
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
it fails with:
{noformat}
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema
document 'null', because 1) could not find the document; 2) the document
could not be read; 3) the root element of the document is not xsd:schema.
{noformat}
The streamsource object in the validator is populated, but the buffered
inputstream object has no content
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6317) Camel-validator not able to resolve schema when using useSharedSchema=false
David J. M. Karlsen created CAMEL-6317:
--
Summary: Camel-validator not able to resolve schema when using
useSharedSchema=false
Key: CAMEL-6317
URL: https://issues.apache.org/jira/browse/CAMEL-6317
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.11.0
Environment: et2448@ubuntu:~/projects/payment/cashpool/server$
/opt/ibm/ibm-java-i386-60/bin/java -version
java version 1.6.0
Java(TM) SE Runtime Environment (build pxi3260sr13fp1-20130325_01(SR13 FP1))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32
jvmxi3260sr13-20130114_134867 (JIT enabled, AOT enabled)
J9VM - 20130114_134867
JIT - r9_20130108_31100
GC - 20121212_AA)
JCL - 20130315_01
Reporter: David J. M. Karlsen
This one works:
{noformat}
to uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd /
{noformat}
This one doesn't:
{noformat}
to
uri=validator:META-INF/xsd/fundscheckmaintainavailablebalance.xsd?useSharedSchema=false
/
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5860) Regression in validator component in 2.10.3
[
https://issues.apache.org/jira/browse/CAMEL-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13640836#comment-13640836
]
David J. M. Karlsen commented on CAMEL-5860:
Are you sure about that? Since it worked just fine on IBM JDK prior to the
camel upgrade?
And it does raise a specific exception due to a specific check inside the jdk
class (which is xerces internalized):
Caused by: javax.xml.transform.TransformerException: Can't transform a Source
of type javax.xml.transform.stax.StAXSource
at
com.sun.org.apache.xerces.internal.jaxp.validation.StAXValidatorHelper.validate(StAXValidatorHelper.java:107)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:154)
Regression in validator component in 2.10.3
---
Key: CAMEL-5860
URL: https://issues.apache.org/jira/browse/CAMEL-5860
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.10.3
Environment: schema on classpath in src/main/resources
Reporter: David J. M. Karlsen
Assignee: Willem Jiang
Fix For: 2.9.6, 2.10.4, 2.11.0
I get:
{code}
CaughtExceptionType:java.lang.NullPointerException,
CaughtExceptionMessage:null, StackTrace:java.lang.NullPointerException at
org.apache.camel.converter.jaxp.XmlConverter.toStreamSource(XmlConverter.java:516)
at
org.apache.camel.converter.jaxp.XmlConverter.toSAXSource(XmlConverter.java:399)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
java.lang.reflect.Method.invoke(Method.java:601) at
org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:923)
at
org.apache.camel.impl.converter.InstanceMethodTypeConverter.convertTo(InstanceMethodTypeConverter.java:66)
at
org.apache.camel.support.TypeConverterSupport.convertTo(TypeConverterSupport.java:34)
at
org.apache.camel.processor.validation.ValidatingProcessor.getSource(ValidatingProcessor.java:343)
at
org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:100)
at
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
at
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
\
{code}
when I upgrade camel to 2.10.3 and use the validator component:
{noformat}
camel:to uri=validator:META-INF/xsd/transactiongatetransfertransaction.xsd
/
{noformat}
this did not happen in 2.10.2 or versions before that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6307) Regression in 2.11.0 bean invocation
David J. M. Karlsen created CAMEL-6307:
--
Summary: Regression in 2.11.0 bean invocation
Key: CAMEL-6307
URL: https://issues.apache.org/jira/browse/CAMEL-6307
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.11.0
Environment: N/A
Reporter: David J. M. Karlsen
When upgradring from 2.10.2 to 2.11.0 I met this regression:
I have a step in my route which invokes a bean:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap( ${body} ) /
{noformat}
after the upgrade it threw:
{noformat}
org.apache.camel.CamelExecutionException: Exception occurred during execution
on the exchange: Exchange[Message: BeanInvocation public abstract
com.mycomp.Transfer com.mycomp.TransferService.doTransfer(com.mycomp.Transfer)
with [com.mycomp.Transfer@7e299629[.
Caused by: org.apache.camel.NoTypeConversionAvailableException: No type
converter available to convert from type: java.lang.String to the required
type: com.mycomp.Transfer with value
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:181)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:149)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.component.bean.MethodInfo$2.evaluateParameterValue(MethodInfo.java:540)
~[camel-core-2.11.0.jar:2.11.0]
{noformat}
If I change the route to:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap(${body}) /
{noformat}
(notice no whitespace before/after ${body} it works as before.
The problematic code seems to be in org.apache.camel.component.bean.MethodInfo
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6307) Regression in 2.11.0 bean invocation
[
https://issues.apache.org/jira/browse/CAMEL-6307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated CAMEL-6307:
---
Description:
When upgradring from 2.10.2 to 2.11.0 I met this regression:
I have a step in my route which invokes a bean:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap( ${body} ) /
{noformat}
after the upgrade it threw:
{noformat}
org.apache.camel.CamelExecutionException: Exception occurred during execution
on the exchange: Exchange[Message: BeanInvocation public abstract
com.mycomp.Transfer com.mycomp.TransferService.doTransfer(com.mycomp.Transfer)
with [com.mycomp.Transfer@7e299629[.
Caused by: org.apache.camel.NoTypeConversionAvailableException: No type
converter available to convert from type: java.lang.String to the required
type: com.mycomp.Transfer with value
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:181)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:149)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.component.bean.MethodInfo$2.evaluateParameterValue(MethodInfo.java:540)
~[camel-core-2.11.0.jar:2.11.0]
{noformat}
If I change the route to:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap(${body}) /
{noformat}
(notice if no whitespace before/after ${body} it works as before).
The problematic code seems to be in org.apache.camel.component.bean.MethodInfo
was:
When upgradring from 2.10.2 to 2.11.0 I met this regression:
I have a step in my route which invokes a bean:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap( ${body} ) /
{noformat}
after the upgrade it threw:
{noformat}
org.apache.camel.CamelExecutionException: Exception occurred during execution
on the exchange: Exchange[Message: BeanInvocation public abstract
com.mycomp.Transfer com.mycomp.TransferService.doTransfer(com.mycomp.Transfer)
with [com.mycomp.Transfer@7e299629[.
Caused by: org.apache.camel.NoTypeConversionAvailableException: No type
converter available to convert from type: java.lang.String to the required
type: com.mycomp.Transfer with value
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:181)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:149)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.component.bean.MethodInfo$2.evaluateParameterValue(MethodInfo.java:540)
~[camel-core-2.11.0.jar:2.11.0]
{noformat}
If I change the route to:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap(${body}) /
{noformat}
(notice no whitespace before/after ${body} it works as before.
The problematic code seems to be in org.apache.camel.component.bean.MethodInfo
Regression in 2.11.0 bean invocation
Key: CAMEL-6307
URL: https://issues.apache.org/jira/browse/CAMEL-6307
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.11.0
Environment: N/A
Reporter: David J. M. Karlsen
Labels: argument, beaninvocation, parse
When upgradring from 2.10.2 to 2.11.0 I met this regression:
I have a step in my route which invokes a bean:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap( ${body} ) /
{noformat}
after the upgrade it threw:
{noformat}
org.apache.camel.CamelExecutionException: Exception occurred during execution
on the exchange: Exchange[Message: BeanInvocation public abstract
com.mycomp.Transfer
com.mycomp.TransferService.doTransfer(com.mycomp.Transfer) with
[com.mycomp.Transfer@7e299629[.
Caused by: org.apache.camel.NoTypeConversionAvailableException: No type
converter available to convert from type: java.lang.String to the required
type: com.mycomp.Transfer with value
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:181)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:149)
~[camel-core-2.11.0.jar:2.11.0]
at
org.apache.camel.component.bean.MethodInfo$2.evaluateParameterValue(MethodInfo.java:540)
~[camel-core-2.11.0.jar:2.11.0]
{noformat}
If I change the route to:
{noformat}
camel:to uri=bean:transferConverter?method=transferToMultimap(${body}) /
{noformat}
(notice if no whitespace before/after ${body} it works as before).
The problematic code seems to be in
[jira] [Created] (CAMEL-6251) Not possible to use propertyplaceholders for camel dataformat pretty-print attribute
David J. M. Karlsen created CAMEL-6251:
--
Summary: Not possible to use propertyplaceholders for camel
dataformat pretty-print attribute
Key: CAMEL-6251
URL: https://issues.apache.org/jira/browse/CAMEL-6251
Project: Camel
Issue Type: Improvement
Components: camel-jaxb
Affects Versions: 2.10.2
Reporter: David J. M. Karlsen
It's not possible to use propertyplaceholders for the prettyPrint attribute for
the jaxb configuration when using spring DSL.
{noformat}
marshal
jaxb prettyPrint=${jaxb.prettyPrint}
contextPath=my.contextpath
partClass=my.Document
partNamespace={my}Document /
/marshal
{noformat}
It will print:
Caused by: org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1:
'${jaxb.prettyPrint}' is not a valid value for 'boolean'.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6211) Migrate to Jackson 2.x libraries
[ https://issues.apache.org/jira/browse/CAMEL-6211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614433#comment-13614433 ] David J. M. Karlsen commented on CAMEL-6211: Duplicate of https://issues.apache.org/jira/browse/CAMEL-6122 Migrate to Jackson 2.x libraries Key: CAMEL-6211 URL: https://issues.apache.org/jira/browse/CAMEL-6211 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: Jason Chaffee Subject says it all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6122) Upgrade component to jackson2
David J. M. Karlsen created CAMEL-6122: -- Summary: Upgrade component to jackson2 Key: CAMEL-6122 URL: https://issues.apache.org/jira/browse/CAMEL-6122 Project: Camel Issue Type: Improvement Components: camel-jackson Reporter: David J. M. Karlsen Upgrade to jackson2. Note: Jackson2 has changed GAV. GroupId is now com.fasterxml.jackson -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6113) Upgrade to Spring 3.2.1.RELEASE
David J. M. Karlsen created CAMEL-6113: -- Summary: Upgrade to Spring 3.2.1.RELEASE Key: CAMEL-6113 URL: https://issues.apache.org/jira/browse/CAMEL-6113 Project: Camel Issue Type: Improvement Components: camel-spring Reporter: David J. M. Karlsen The Spring 3.1.x series won't get any more fixes, maybe it's time to move on to latest 3.2.x? CAMEL-4778 is somewhat related. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CAMEL-5860) Regression in validator component in 2.10.3
[
https://issues.apache.org/jira/browse/CAMEL-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen reopened CAMEL-5860:
Regression: Regression
It now fails with:
{noformat}
Caused by: javax.xml.transform.TransformerException: Can't transform a Source
of type javax.xml.transform.stax.StAXSource
at
com.sun.org.apache.xerces.internal.jaxp.validation.StAXValidatorHelper.validate(StAXValidatorHelper.java:107)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:154)
at
org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:127)
at
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
at
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at
org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:117)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:122)
at
org.apache.camel.processor.RouteInflightRepositoryProcessor.processNext(RouteInflightRepositoryProcessor.java:48)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:61)
at
org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:86)
at
org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:366)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:337)
at
org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:233)
at
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:337)
at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:175)
at
[jira] [Comment Edited] (CAMEL-5860) Regression in validator component in 2.10.3
[
https://issues.apache.org/jira/browse/CAMEL-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588133#comment-13588133
]
David J. M. Karlsen edited comment on CAMEL-5860 at 2/27/13 10:03 AM:
--
It now fails on IBM java 1.6 JDK with:
{noformat}
Caused by: javax.xml.transform.TransformerException: Can't transform a Source
of type javax.xml.transform.stax.StAXSource
at
com.sun.org.apache.xerces.internal.jaxp.validation.StAXValidatorHelper.validate(StAXValidatorHelper.java:107)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:154)
at
org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:127)
at
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
at
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at
org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:117)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:122)
at
org.apache.camel.processor.RouteInflightRepositoryProcessor.processNext(RouteInflightRepositoryProcessor.java:48)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:61)
at
org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:86)
at
org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:366)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:337)
at
org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:233)
at
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:337)
at
[jira] [Comment Edited] (CAMEL-5860) Regression in validator component in 2.10.3
[
https://issues.apache.org/jira/browse/CAMEL-5860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13588133#comment-13588133
]
David J. M. Karlsen edited comment on CAMEL-5860 at 2/27/13 12:17 PM:
--
It now (in 2.10.4) fails on IBM java 1.6 JDK with:
{noformat}
Caused by: javax.xml.transform.TransformerException: Can't transform a Source
of type javax.xml.transform.stax.StAXSource
at
com.sun.org.apache.xerces.internal.jaxp.validation.StAXValidatorHelper.validate(StAXValidatorHelper.java:107)
at
com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:154)
at
org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:127)
at
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
at
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:163)
at
org.apache.camel.processor.interceptor.StreamCachingInterceptor.process(StreamCachingInterceptor.java:52)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:308)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:117)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
at
org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:122)
at
org.apache.camel.processor.RouteInflightRepositoryProcessor.processNext(RouteInflightRepositoryProcessor.java:48)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:61)
at
org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150)
at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:99)
at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:86)
at
org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:63)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:366)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:337)
at
org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:233)
at
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:337)
at
[jira] [Commented] (CAMEL-3957) New CommonJ workmanager component
[ https://issues.apache.org/jira/browse/CAMEL-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542851#comment-13542851 ] David J. M. Karlsen commented on CAMEL-3957: There is also an abstraction available through Spring: http://static.springsource.org/spring/docs/3.2.x/javadoc-api/org/springframework/scheduling/commonj/package-frame.html chapter 27: http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/htmlsingle/ but you might want a clean native camel integration and leave spring out of the equation? New CommonJ workmanager component - Key: CAMEL-3957 URL: https://issues.apache.org/jira/browse/CAMEL-3957 Project: Camel Issue Type: New Feature Reporter: Preben Asmussen Priority: Minor Fix For: Future Attachments: camel-core.patch For story see http://camel.465427.n5.nabble.com/Camel-CommonJ-component-for-Camel-running-in-jee-servers-td4375746.html I have fixed up the work done by others so it hopefully can be part of Camel (core or separate component). The source is available at GitHub https://github.com/pax95/camel-commonj project depends currently on Camel 2.7.1 (small change to camel-core would be nice whereas I can remove duplicated code - see attached patch and TODO in code) To be done - More tests - please advise on scope. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5860) Regression in validator component in 2.10.3
David J. M. Karlsen created CAMEL-5860:
--
Summary: Regression in validator component in 2.10.3
Key: CAMEL-5860
URL: https://issues.apache.org/jira/browse/CAMEL-5860
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.10.3
Environment: schema on classpath in src/main/resources
Reporter: David J. M. Karlsen
I get:
{noformat}
CaughtExceptionType:java.lang.NullPointerException,
CaughtExceptionMessage:null, StackTrace:java.lang.NullPointerException at
org.apache.camel.converter.jaxp.XmlConverter.toStreamSource(XmlConverter.java:516)
at
org.apache.camel.converter.jaxp.XmlConverter.toSAXSource(XmlConverter.java:399)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601) at
org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:923) at
org.apache.camel.impl.converter.InstanceMethodTypeConverter.convertTo(InstanceMethodTypeConverter.java:66)
at
org.apache.camel.support.TypeConverterSupport.convertTo(TypeConverterSupport.java:34)
at
org.apache.camel.processor.validation.ValidatingProcessor.getSource(ValidatingProcessor.java:343)
at
org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:100)
at
org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
at
org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71) at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117) at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)
{noformat}
when I upgrade camel to 2.10.3 and use the validator component:
{noformat}
camel:to
uri=validator:META-INF/xsd/transactiongatetransfertransaction.xsd /
{noformat}
this did not happen in 2.10.2 or versions before that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5840) Publish schema to www
David J. M. Karlsen created CAMEL-5840: -- Summary: Publish schema to www Key: CAMEL-5840 URL: https://issues.apache.org/jira/browse/CAMEL-5840 Project: Camel Issue Type: Task Components: documentation Affects Versions: 2.10.2 Reporter: David J. M. Karlsen http://camel.apache.org/schema/spring/camel-spring-2.10.2.xsd gives a 404 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5356) CXF endpoint doesn't play nice with doTry/doCatch
[ https://issues.apache.org/jira/browse/CAMEL-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13496218#comment-13496218 ] David J. M. Karlsen commented on CAMEL-5356: Any news on this? My onException handling is never called. If it makes any difference this is an inOnly webservice. I've set handleException true and handleFault=true. CXF endpoint doesn't play nice with doTry/doCatch - Key: CAMEL-5356 URL: https://issues.apache.org/jira/browse/CAMEL-5356 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.3 Reporter: Jens Granseuer Fix For: Future Attachments: camelTryCatch.zip When using a CXF client endpoint to call a web service via SOAP/HTTP there are two possible error scenarios: 1) The call fails immediately with an exception (e.g. because the service is down/the address is wrong) 2) The call succeeds but returns a SOAP fault. This could also signal an error condition to the application. Currently, using doTry/doCatch doesn't work properly in either scenario because, apprently, the CXF endpoint nulls the message when receiving an exception or fault. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-5356) CXF endpoint doesn't play nice with doTry/doCatch
[ https://issues.apache.org/jira/browse/CAMEL-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen updated CAMEL-5356: --- Comment: was deleted (was: Any news on this? My onException handling is never called. If it makes any difference this is an inOnly webservice. I've set handleException true and handleFault=true.) CXF endpoint doesn't play nice with doTry/doCatch - Key: CAMEL-5356 URL: https://issues.apache.org/jira/browse/CAMEL-5356 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.8.3 Reporter: Jens Granseuer Fix For: Future Attachments: camelTryCatch.zip When using a CXF client endpoint to call a web service via SOAP/HTTP there are two possible error scenarios: 1) The call fails immediately with an exception (e.g. because the service is down/the address is wrong) 2) The call succeeds but returns a SOAP fault. This could also signal an error condition to the application. Currently, using doTry/doCatch doesn't work properly in either scenario because, apprently, the CXF endpoint nulls the message when receiving an exception or fault. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-5777) Misleading docs on wiki
David J. M. Karlsen created CAMEL-5777: -- Summary: Misleading docs on wiki Key: CAMEL-5777 URL: https://issues.apache.org/jira/browse/CAMEL-5777 Project: Camel Issue Type: Bug Components: documentation Affects Versions: 2.10.2 Environment: N/A Reporter: David J. M. Karlsen Priority: Minor On http://camel.apache.org/jms.html it says acknowledgementModeNameAUTO_ACKNOWLEDGE The JMS acknowledgement name, which is one of: TRANSACTED, CLIENT_ACKNOWLEDGE, AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE these seems to be constants off the interface: http://docs.oracle.com/javaee/1.4/api/javax/jms/Session.html Thus it should read: SESSION_TRANSACTED and NOT TRANSACTED. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-5675) Camel Route Startup Performance Slow
[ https://issues.apache.org/jira/browse/CAMEL-5675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468392#comment-13468392 ] David J. M. Karlsen commented on CAMEL-5675: You could maybe use commons which has introspection cache already? http://commons.apache.org/beanutils/xref/org/apache/commons/beanutils/PropertyUtils.html Camel Route Startup Performance Slow Key: CAMEL-5675 URL: https://issues.apache.org/jira/browse/CAMEL-5675 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.8.6 Environment: JDK 1.6 Reporter: Les Novell Assignee: Claus Ibsen Labels: performance I am writing unit tests for Camel and found that each unit test was taking up to a second just to create the Camel routes. That's not very long, but we have a large unit test suite that needs to run quickly. I did a performance profile and found that most of the time is going to the method org.apache.camel.util.IntrospectionSupport.getProperties(Object, Map, String). That method, then also calls IntrospectionSupport.isSetter(Method), and just running two unit tests I saw isSettter called 2.5 million times! It seems to me that a cache per class of the properties would make a huge performance improvement on Camel route building. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
