[jira] [Commented] (CAMEL-7880) Cannot use custom DataFormats in REST DSL
[
https://issues.apache.org/jira/browse/CAMEL-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233994#comment-14233994
]
Claus Ibsen commented on CAMEL-7880:
Okay so the intention is that setting a custom data format refers only to its
name, not to a pre configured instance from the registry. So I am adding that
as a validation to fail if so.
Cannot use custom DataFormats in REST DSL
-
Key: CAMEL-7880
URL: https://issues.apache.org/jira/browse/CAMEL-7880
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Sohrab Hosseini
Assignee: Claus Ibsen
Fix For: 2.14.1, 2.15.0
Attachments: camel-rest-dataformat-test.groovy
See:
http://camel.465427.n5.nabble.com/RestBindingProcessor-JSON-Data-Format-Config-td5757103.html
When using custom JSON data format in REST DSL, the service incorrectly
rejects messages with request structure and accepts messages with response
structure.
This is due to
{{org.apache.camel.model.rest.RestBindingDefinition.createProcessor(RouteContext)}}
looking up and configuring the same DataFormat object twice:
{code:java}
DataFormat json = context.resolveDataFormat(name);
DataFormat outJson = context.resolveDataFormat(name);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7880) Cannot use custom DataFormats in REST DSL
[
https://issues.apache.org/jira/browse/CAMEL-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7880.
Resolution: Fixed
Cannot use custom DataFormats in REST DSL
-
Key: CAMEL-7880
URL: https://issues.apache.org/jira/browse/CAMEL-7880
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Reporter: Sohrab Hosseini
Assignee: Claus Ibsen
Fix For: 2.14.1, 2.15.0
Attachments: camel-rest-dataformat-test.groovy
See:
http://camel.465427.n5.nabble.com/RestBindingProcessor-JSON-Data-Format-Config-td5757103.html
When using custom JSON data format in REST DSL, the service incorrectly
rejects messages with request structure and accepts messages with response
structure.
This is due to
{{org.apache.camel.model.rest.RestBindingDefinition.createProcessor(RouteContext)}}
looking up and configuring the same DataFormat object twice:
{code:java}
DataFormat json = context.resolveDataFormat(name);
DataFormat outJson = context.resolveDataFormat(name);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8117) set encoding on a per-message basis
[ https://issues.apache.org/jira/browse/CAMEL-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8117. Resolution: Fixed Fix Version/s: 2.15.0 Assignee: Claus Ibsen set encoding on a per-message basis --- Key: CAMEL-8117 URL: https://issues.apache.org/jira/browse/CAMEL-8117 Project: Camel Issue Type: Improvement Components: camel-smpp Affects Versions: 2.14.0 Reporter: Daniel Pocock Assignee: Claus Ibsen Priority: Minor Fix For: 2.15.0 There is an endpoint property for setting the encoding. It would be useful to set this on a per-message basis with a header too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8117) set encoding on a per-message basis
[ https://issues.apache.org/jira/browse/CAMEL-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234033#comment-14234033 ] Claus Ibsen commented on CAMEL-8117: Daniel, you are welcome to help update the documentation at http://camel.apache.org/smpp set encoding on a per-message basis --- Key: CAMEL-8117 URL: https://issues.apache.org/jira/browse/CAMEL-8117 Project: Camel Issue Type: Improvement Components: camel-smpp Affects Versions: 2.14.0 Reporter: Daniel Pocock Assignee: Claus Ibsen Priority: Minor Fix For: 2.15.0 There is an endpoint property for setting the encoding. It would be useful to set this on a per-message basis with a header too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8122) camel:run using useBlueprint option does not launch camel example project
Charles Moulliard created CAMEL-8122:
Summary: camel:run using useBlueprint option does not launch
camel example project
Key: CAMEL-8122
URL: https://issues.apache.org/jira/browse/CAMEL-8122
Project: Camel
Issue Type: Bug
Components: examples
Affects Versions: 2.15.0
Reporter: Charles Moulliard
When we launch the maven camel:run goal with the camel-example-sql-blueprint,
the camel project is not started and this OSGI Service error is reported.
I suspect that some bundles are missing and not loaded by the PoJoSr
classloader when the project is started/launched by the camel-maven-plugin
See line of code
{code}
package org.apache.camel.maven;
...
public class RunMojo extends AbstractExecMojo {
...
} else if (usingBlueprintMain) {
mainClass = org.apache.camel.test.blueprint.Main;
// must include plugin dependencies for blueprint
extraPluginDependencyArtifactId = camel-test-blueprint;
{code}
{code}
Caused by: java.lang.RuntimeException: Gave up waiting for service
(objectClass=org.apache.camel.CamelContext)
[INFO] --- camel-maven-plugin:2.15-SNAPSHOT:run (default-cli) @
camel-example-sql-blueprint ---
[INFO] Using org.apache.camel.test.blueprint.Main to initiate a CamelContext
[INFO] Starting Camel ...
[mel.test.blueprint.Main.main()] MainSupportINFO Apache
Camel 2.15-SNAPSHOT starting
[mel.test.blueprint.Main.main()] Activator INFO Camel
activator starting
[mel.test.blueprint.Main.main()] Activator INFO Camel
activator started
[mel.test.blueprint.Main.main()] BlueprintExtender INFO No
quiesce support is available, so blueprint components will not participate in
quiesce operations
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN Test
bundle headers: Bundle-ManifestVersion=2, Bundle-Name=System Bundle,
Bundle-SymbolicName=de.kalpatec.pojosr.framework, Bundle-Vendor=kalpatec,
Bundle-Version=0.2.1
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.camel.spi.TypeConverterLoader], bundle:
org.apache.camel.camel-core [3], symbolicName: org.apache.camel.camel-core
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.camel.camel-blueprint [2], symbolicName:
org.apache.camel.camel-blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.proxy.ProxyManager], bundle:
org.apache.aries.proxy.impl [19], symbolicName: org.apache.aries.proxy.impl
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ConfigurationAdmin], bundle:
org.apache.felix.configadmin [28], symbolicName: org.apache.felix.configadmin
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.felix.cm.PersistenceManager], bundle:
org.apache.felix.configadmin [28], symbolicName: org.apache.felix.configadmin
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ManagedServiceFactory], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ConfigurationListener,
org.apache.felix.fileinstall.ArtifactListener,
org.apache.felix.fileinstall.ArtifactInstaller], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.url.URLStreamHandlerService], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.services.ParserService], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference:
[jira] [Updated] (CAMEL-8122) camel:run using useBlueprint option does not launch camel example project
[
https://issues.apache.org/jira/browse/CAMEL-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard updated CAMEL-8122:
-
Description:
When we launch the maven camel:run goal with the camel-example-sql-blueprint,
the camel project is not started and this OSGI Service error is reported.
I suspect that some bundles are missing and not loaded by the PoJoSr
classloader when the project is started/launched by the camel-maven-plugin
See line of code
{code}
package org.apache.camel.maven;
...
public class RunMojo extends AbstractExecMojo {
...
} else if (usingBlueprintMain) {
mainClass = org.apache.camel.test.blueprint.Main;
// must include plugin dependencies for blueprint
extraPluginDependencyArtifactId = camel-test-blueprint;
{code}
Error reported on the console
{code}
Caused by: java.lang.RuntimeException: Gave up waiting for service
(objectClass=org.apache.camel.CamelContext)
[INFO] --- camel-maven-plugin:2.15-SNAPSHOT:run (default-cli) @
camel-example-sql-blueprint ---
[INFO] Using org.apache.camel.test.blueprint.Main to initiate a CamelContext
[INFO] Starting Camel ...
[mel.test.blueprint.Main.main()] MainSupportINFO Apache
Camel 2.15-SNAPSHOT starting
[mel.test.blueprint.Main.main()] Activator INFO Camel
activator starting
[mel.test.blueprint.Main.main()] Activator INFO Camel
activator started
[mel.test.blueprint.Main.main()] BlueprintExtender INFO No
quiesce support is available, so blueprint components will not participate in
quiesce operations
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN Test
bundle headers: Bundle-ManifestVersion=2, Bundle-Name=System Bundle,
Bundle-SymbolicName=de.kalpatec.pojosr.framework, Bundle-Vendor=kalpatec,
Bundle-Version=0.2.1
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.camel.spi.TypeConverterLoader], bundle:
org.apache.camel.camel-core [3], symbolicName: org.apache.camel.camel-core
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.camel.camel-blueprint [2], symbolicName:
org.apache.camel.camel-blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.proxy.ProxyManager], bundle:
org.apache.aries.proxy.impl [19], symbolicName: org.apache.aries.proxy.impl
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ConfigurationAdmin], bundle:
org.apache.felix.configadmin [28], symbolicName: org.apache.felix.configadmin
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.felix.cm.PersistenceManager], bundle:
org.apache.felix.configadmin [28], symbolicName: org.apache.felix.configadmin
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ManagedServiceFactory], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ConfigurationListener,
org.apache.felix.fileinstall.ArtifactListener,
org.apache.felix.fileinstall.ArtifactInstaller], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.url.URLStreamHandlerService], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.services.ParserService], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference:
[jira] [Comment Edited] (CAMEL-5719) ZooKeeper route policy should initialize using onInit to elect master
[ https://issues.apache.org/jira/browse/CAMEL-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233674#comment-14233674 ] Ioannis Alexandrakis edited comment on CAMEL-5719 at 12/4/14 9:01 AM: -- There is another issue I wanted to address, which applies here (and in the original component, too). Perhaps it deserves its own ticket, perhaps not, perhaps it does not deserve a ticket at all. Following the above example, if someone has, for instance, activemq components, just stopping the consumers (edit: the endpoint's consumers, not the activemq consumers) is not 'safe' enough. I noticed that (prefetch size * consumer count) messages (I had 2 consumers with prefetch 1, so, all in all, 2 messages) are neither being processed, not forwarded further. They stay in 'inflight' mode. My setup is a store and forward network of activemq brokers. So, a queue on node A, if it does not have any (activemq) consumers, it forwards to a node B which has. In my case, the elected as master node would have to get the activemq messages, even though I sent jms messages to node A, which was not elected from zookeeper. Instead, it skipped (prefetch size * consumer count) messages before the rest got forwarded (the skipped ones stayed in node B as 'inflight', apparently it awaits for the endpoint consumers to be started). If, instead of stopping the consumers, I was to stop the route itself, then the component did not get those messages as inflight and all messages got forwarded immediately. I have a patch available on top of the above one (it just stops the route where it stops the consumers of the endpoint, and starts the route wherever it starts the consumers. The idea is the same, but instead of consumers, the whole route gets started/stoped). I can attach it, if you like. This is a matter of opinion, really. If someone sets the prefetch size = 0, then there is no problem. However, it would drop the performance significantly. In my opinion, however (in any case), I think the zookeeper policy should 'stop' the route entirely. I do not know if such a behaviour exists in other components (like jms/activemq's prefetch size and the inflight exchanges problem). So, perhaps this is a really unique/specific case. was (Author: ialex): There is another issue I wanted to address, which applies here (and in the original component, too). Perhaps it deserves its own ticket, perhaps not, perhaps it does not deserve a ticket at all. Following the above example, if someone has, for instance, activemq components, just stopping the consumers is not 'safe' enough. I noticed that (prefetch size * consumer count) messages (I had 2 consumers with prefetch 1, so, all in all, 2 messages) are neither being processed, not forwarded further. They stay in 'inflight' mode. My setup is a store and forward network of activemq brokers. So, a queue on node A, if it does not have any consumers, it forwards to a node B which has. In my case, the elected as master node would have to get the activemq messages, even though I sent jms messages to node A, which was not elected from zookeeper. Instead, it skipped (prefetch size * consumer count) messages before the rest got forwarded (the skipped ones stayed in node B as 'inflight'). If, instead of stopping the consumers, I was to stop the route itself, then the component did not get those messages as inflight and all messages got forwarded immediately. I have a patch available on top of the above one (it just stops the route where it stops the consumers of the endpoint, and starts the route wherever it starts the consumers. The idea is the same, but instead of consumers, the whole route gets started/stoped). I can attach it, if you like. This is a matter of opinion, really. If someone sets the prefetch size = 0, then there is no problem. However, it would drop the performance significantly. In my opinion, however (in any case), I think the zookeeper policy should 'stop' the route entirely. I do not know if such a behaviour exists in other components (like jms/activemq's prefetch size and the inflight exchanges problem). So, perhaps this is a really unique/specific case. ZooKeeper route policy should initialize using onInit to elect master - Key: CAMEL-5719 URL: https://issues.apache.org/jira/browse/CAMEL-5719 Project: Camel Issue Type: Improvement Components: camel-zookeeper Affects Versions: 2.10.0 Reporter: Claus Ibsen Fix For: Future Attachments: zookeeper-election.patch See nabble http://camel.465427.n5.nabble.com/Single-instance-of-running-route-in-the-cluster-tp5720846.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-5719) ZooKeeper route policy should initialize using onInit to elect master
[ https://issues.apache.org/jira/browse/CAMEL-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14233431#comment-14233431 ] Ioannis Alexandrakis edited comment on CAMEL-5719 at 12/4/14 9:04 AM: -- I wanted the same thing; having a single instance running from the creation of the camel context. The way the policy currently works is that it waits for the first exchange to stop the consumers from processing. It might be useful if the exchange is expendable (e.g. route is a *file* component or something of the sort). If it is not, (e.g. a *jetty* or an *activemq* component), it would mean that the +first exchange (if it happens to arrive on a 'secondary' camel route) would be 'lost'+ and if it hasn't been thought through, it might mean problems in the application. The most useful approach would be to not start the route on the onInit phase. However, there are some inherent problems (for example, the context is not yet fully started between all those phases and I think you can't mark a route as autoStartup = false in any of the RoutePolicy's methods, it won't work, and the context is not yet fully initialized). Moreover, the component itself 'injects' another route (election-route-) in the camel context itself, which makes the things even more complicated. One way would be to setAutoStartup(false) in the camel context containing the routes. However, if you have routes that you don't want to be suspended from the beginning, this would create problems. This would not start the injected election route from the above paragraph too. And you can't get a callback (apart from the StartupListener interface, I couldn't find anything else that could help). h5. In the end, I managed to get the expected behaviour by doing the following: *1)* Created a new camel context (this could be static, for performance reasons, but I do not think it has a large overhead), in which I put the election route, just to be easily manageable, and to distinguish it from the others. This has the downside that you have to manually start/stop it (however I think it is not a problem, I close it overriding the +doShutdown()+). *2)* For each route, overrode the +onStart(Route route)+ and check whether the node +isMaster+. If it is not, stop its consumers (this way, it doesn't get to process anything yet, and we assume it is 'paused'). We might be able to avoid the step above with the new camel context, if we make sure that the +onStart(Route route)+ is not run for the election route (because it would create a deadlock). However, I like the idea of the election route being separate (in karaf the route was appearing when I was scanning the camel contexts. When it was alone, it was 'hidden') So, having those modifications, we get the benefit of having the route without consumers if it is not a primary node on startup, however on any election change, the consumer(s) will be started. I tested it within karaf, and the behaviour was what I expected, single instance of a route running at all times. (+the attached patch is from 2.14.1-SNAPSHOT+) Note: after these checks, I think the +onExchangeBegin(Route route, Exchange exchange)+ does not need the check the election. However, I did not modify anything there, just for safety. was (Author: ialex): I wanted the same thing; having a single instance running from the creation of the camel context. The way the policy currently works is that it waits for the first exchange to stop the consumers from processing. It might be useful if the exchange is expendable (e.g. route is a *file* component or something of the sort). If it is not, (e.g. a *jetty* or an *activemq* component), it would mean that the +first exchange (if it happens to arrive on a 'secondary' camel route) would be 'lost'+ and if it hasn't been thought through, it might mean problems in the application. The most useful approach would be to not start the route on the onInit phase. However, there are some inherent problems (for example, the context is not yet fully started between all those phases and there is no easy way to stop the route while the context is not yet fully initialized). Moreover, the component itself 'injects' another route (election-route-) in the camel context itself, which makes the things even more complicated. One way would be to setAutoStartup(false) in the camel context containing the routes. However, if you have routes that you don't want to be suspended from the beginning, this would create problems. This would not start the injected election route from the above paragraph too. And, finally, things get complicated if you try to start/stop routes before the context is fully started. And you can't get a callback (apart from the StartupListener interface, I couldn't find anything else that could help). h5. In the end, I managed to
[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234041#comment-14234041
]
Charles Moulliard commented on CAMEL-7925:
--
I have redeployed my project on Apache Karaf 3.0.2 using Apache Camel 2.14.0
with Groovy 2.3.6 and another classloading issue is reported even if the class
groovy.lang.SCript is well packaged with the bundle Grrovy Runtime
Error
{code}
Caused by: java.lang.ClassNotFoundException: groovy.lang.Script
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:655)
at
groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:408)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:765)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:753)
... 31 more
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:309)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1067)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:583)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:561)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:538)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:286)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:259)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:245)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:203)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:213)[122:groovy-all:2.3.6]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:65)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.language.groovy.GroovyExpression.evaluate(GroovyExpression.java:50)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.builder.ProcessorBuilder$4.process(ProcessorBuilder.java:103)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:157)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:68)[92:org.apache.camel.camel-core:2.14.0]
at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_51]
at java.util.TimerThread.run(Timer.java:505)[:1.7.0_51]
{code}
What is deployed on Karaf
{code}
92 | Active | 50 | 2.14.0 | mvn:org.apache.camel/camel-core/2.14.0
93 | Active | 50 | 2.14.0 |
mvn:org.apache.camel.karaf/camel-karaf-commands/2.14.0
108 | Active | 50 | 1.1.1 |
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
109 | Active | 50 | 2.14.0 | mvn:org.apache.camel/camel-spring/2.14.0
110 | Active | 50 | 2.14.0 |
mvn:org.apache.camel/camel-blueprint/2.14.0
120 | Active | 50 | 1.7.0.6|
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.ant/1.7.0_6
121 | Active | 50 | 2.2.0 |
mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.scripting-api-1.0/2.2.0
122 | Active | 50 | 2.3.6 | mvn:org.codehaus.groovy/groovy-all/2.3.6
123 |
[jira] [Comment Edited] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234041#comment-14234041
]
Charles Moulliard edited comment on CAMEL-7925 at 12/4/14 9:06 AM:
---
I have redeployed my project on Apache Karaf 3.0.2 using Apache Camel 2.14.0
with Groovy 2.3.6 and another classloading issue is reported even if the class
groovy.lang.Script is well packaged with the bundle Groovy Runtime
Error
{code}
Caused by: java.lang.ClassNotFoundException: groovy.lang.Script
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:655)
at
groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:408)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:765)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:753)
... 31 more
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:309)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1067)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:583)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:561)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:538)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:286)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:259)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:245)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:203)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:213)[122:groovy-all:2.3.6]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:65)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.language.groovy.GroovyExpression.evaluate(GroovyExpression.java:50)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.builder.ProcessorBuilder$4.process(ProcessorBuilder.java:103)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:157)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:68)[92:org.apache.camel.camel-core:2.14.0]
at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_51]
at java.util.TimerThread.run(Timer.java:505)[:1.7.0_51]
{code}
What is deployed on Karaf
{code}
92 | Active | 50 | 2.14.0 | mvn:org.apache.camel/camel-core/2.14.0
93 | Active | 50 | 2.14.0 |
mvn:org.apache.camel.karaf/camel-karaf-commands/2.14.0
108 | Active | 50 | 1.1.1 |
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
109 | Active | 50 | 2.14.0 | mvn:org.apache.camel/camel-spring/2.14.0
110 | Active | 50 | 2.14.0 |
mvn:org.apache.camel/camel-blueprint/2.14.0
120 | Active | 50 | 1.7.0.6|
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.ant/1.7.0_6
121 | Active | 50 | 2.2.0 |
mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.scripting-api-1.0/2.2.0
122 | Active | 50 | 2.3.6 |
[jira] [Commented] (CAMEL-8042) CxfClientCallBack handleException does not honour exception
[
https://issues.apache.org/jira/browse/CAMEL-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234042#comment-14234042
]
John McKeogh commented on CAMEL-8042:
-
This is still an issue for us.
CxfClientCallBack handleException does not honour exception
---
Key: CAMEL-8042
URL: https://issues.apache.org/jira/browse/CAMEL-8042
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.11.2, 2.14.0
Environment: Windows
Reporter: John McKeogh
Assignee: Willem Jiang
Fix For: 2.14.1
Attachments: greeter-corba.wsdl
Hi,
Since Camel 2.11.2, The cxfClientCallBack doesn't seem to be honouring the
exception that it is passed in.
Here is a copy of the HandleException funciton before and after 11.2
2.11.1
public void handleException(MapString, Object ctx, Throwable
ex) {
try {
super.handleException(ctx, ex);
camelExchange.setException(ex);
} finally {
// copy
2.11.2
public void handleException(MapString, Object ctx, Throwable ex) {
try {
super.handleException(ctx, ex);
// need to call the conduitSelector complete method to enable the
fail over feature
ConduitSelector conduitSelector =
cxfExchange.get(ConduitSelector.class);
if (conduitSelector != null) {
conduitSelector.complete(cxfExchange);
ex = cxfExchange.getOutMessage().getContent(Exception.class);
if (ex == null cxfExchange.getInMessage() != null) {
ex =
cxfExchange.getInMessage().getContent(Exception.class);
}
if (ex != null) {
camelExchange.setException(ex);
}
} else {
camelExchange.setException(ex);
}
} finally {
So for our testcase where we have a cxf client calling through camel to a
Corba web service, the exception that the webservice is passing back to camel
is no longer honoured.
I believe this change was introduced by the following jira:
https://issues.apache.org/jira/browse/CAMEL-6609
I have attached the wsdl of the corba web-service.
In the service we are calling PingMe expecting to get back a
PingMeFault_Exception. The exception is set in the cxf corba binding and
reached the exception handler in camel. But the exception is no longer being
sent back to the client. Instead a generic SoapFaultException is reaching the
client.
Cheers,
John.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234041#comment-14234041
]
Charles Moulliard edited comment on CAMEL-7925 at 12/4/14 9:07 AM:
---
I have redeployed my project on Apache Karaf 3.0.2 using Apache Camel 2.14.0
with Groovy 2.3.6 and another classloading issue is reported even if the class
groovy.lang.Script is well packaged with the bundle Groovy Runtime
Error
{code}
Caused by: java.lang.ClassNotFoundException: groovy.lang.Script
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:655)
at
groovy.lang.GroovyClassLoader$InnerLoader.loadClass(GroovyClassLoader.java:408)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:765)
at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:753)
... 31 more
1 error
at
org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:309)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1067)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:583)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:561)[122:groovy-all:2.3.6]
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:538)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:286)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:259)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:245)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:203)[122:groovy-all:2.3.6]
at
groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:213)[122:groovy-all:2.3.6]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:65)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.language.groovy.GroovyExpression.evaluate(GroovyExpression.java:50)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.builder.ProcessorBuilder$4.process(ProcessorBuilder.java:103)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:157)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:68)[92:org.apache.camel.camel-core:2.14.0]
at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_51]
at java.util.TimerThread.run(Timer.java:505)[:1.7.0_51]
{code}
What is deployed on Karaf
{code}
92 | Active | 50 | 2.14.0 | mvn:org.apache.camel/camel-core/2.14.0
93 | Active | 50 | 2.14.0 |
mvn:org.apache.camel.karaf/camel-karaf-commands/2.14.0
108 | Active | 50 | 1.1.1 |
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
109 | Active | 50 | 2.14.0 | mvn:org.apache.camel/camel-spring/2.14.0
110 | Active | 50 | 2.14.0 |
mvn:org.apache.camel/camel-blueprint/2.14.0
120 | Active | 50 | 1.7.0.6|
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.ant/1.7.0_6
121 | Active | 50 | 2.2.0 |
mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.scripting-api-1.0/2.2.0
122 | Active | 50 | 2.3.6 |
[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234051#comment-14234051
]
Charles Moulliard commented on CAMEL-7925:
--
Example is available here
:https://github.com/cmoulliard/use-cases/blob/master/camel-osgi-groovy/README.md
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234098#comment-14234098
]
Charles Moulliard commented on CAMEL-7925:
--
If I add dynamic-import package to the demo example, the classloading issue
with groovy.lang.script is gone and I get a similar error :
{code}
2014-12-04 11:22:36,696 | WARN | - timer://groovy | TimerConsumer
| 92 - org.apache.camel.camel-core - 2.14.0 | Error processing exchange.
Exchange[Message: This is a message containing double quotes. Example --
Hello.]. Caused by: [java.lang.ClassCastException -
script1417688554694697720774 cannot be cast to groovy.lang.Script]
java.lang.ClassCastException: script1417688554694697720774 cannot be cast to
groovy.lang.Script
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.language.groovy.GroovyExpression.evaluate(GroovyExpression.java:50)[123:org.apache.camel.camel-groovy:2.14.0]
at
org.apache.camel.builder.ProcessorBuilder$4.process(ProcessorBuilder.java:103)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:118)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.Pipeline.process(Pipeline.java:80)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer.sendTimerExchange(TimerConsumer.java:157)[92:org.apache.camel.camel-core:2.14.0]
at
org.apache.camel.component.timer.TimerConsumer$1.run(TimerConsumer.java:68)[92:org.apache.camel.camel-core:2.14.0]
at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_51]
at java.util.TimerThread.run(Timer.java:505)[:1.7.0_51]
{code}
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234100#comment-14234100
]
Charles Moulliard commented on CAMEL-7925:
--
It seems that the problem reported is related to Felix issue -
https://issues.apache.org/jira/browse/CAMEL-5493
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234121#comment-14234121
]
Charles Moulliard commented on CAMEL-7925:
--
Problem resolved using DynamicImport-Package*/DynamicImport-Package
features camel-script, camel-script-groovy
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard resolved CAMEL-7925.
--
Resolution: Fixed
See last comment
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Moulliard reassigned CAMEL-7925:
Assignee: Charles Moulliard
groovy and osgi - Could not initialize class script1413536396719697720774
-
Key: CAMEL-7925
URL: https://issues.apache.org/jira/browse/CAMEL-7925
Project: Camel
Issue Type: Bug
Components: camel-groovy
Environment: Apache Karaf 2.2.x
Reporter: Charles Moulliard
Assignee: Charles Moulliard
Priority: Minor
When a camel route is deployed on apache Karaf using a groovy expression to
be evaluated we get this error
https://gist.github.com/cmoulliard/7294122c47e9c18df399
Route
{code}
from(direct:launch).routeId(request-token)
.onException(HttpOperationFailedException.class)
.handled(true)
.log(An error occurred)
.to(direct:interface-status)
.end()
.setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
.setHeader(Exchange.HTTP_QUERY, constant(User= + UserName +
+ Pass= + Password))
.setHeader(Exchange.HTTP_METHOD, constant(GET))
.to(https4://token-service)
.convertBodyTo(String.class)
.setHeader(token).groovy(body.replaceAll('\',''))
{code}
{code}
Caused by: java.lang.NoClassDefFoundError: Could not initialize class
script1413536396719697720774
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)[:1.7.0_51]
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
at
java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
at
org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8123) Mina2 SSL initiates handshake backwards
Justin Cozzens created CAMEL-8123: - Summary: Mina2 SSL initiates handshake backwards Key: CAMEL-8123 URL: https://issues.apache.org/jira/browse/CAMEL-8123 Project: Camel Issue Type: Bug Components: camel-mina2 Affects Versions: 2.14.0, 2.13.3 Reporter: Justin Cozzens The Mina2Consumer and Mina2Producer are configured backwards for SSL handshake initiation. The consumer is trying to initiate the handshake rather than the producer. You can see this by setting up a SSL enabled consuming route and telnet to the port, you will immediately get some data sent from the server to the client rather than the server waiting on the client to initiate the handshake. The issue is Mina2Consumer:160, it is setting UseClientMode to true, it should be false. Mina2Producer line 313 needs to also change to the following: SslFilter filter = new SslFilter(configuration.getSslContextParameters().createSSLContext(), configuration.isAutoStartTls()); filter.setUseClientMode(true); connector.getFilterChain().addFirst(sslFilter, filter); As far as I can tell this has been a bug since this component was introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7794) Topics support in camel-hazelcast
[ https://issues.apache.org/jira/browse/CAMEL-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234260#comment-14234260 ] Juan Jose Vazquez Delgado commented on CAMEL-7794: -- Of course. My username is 'jvazquez' and I already have a CLA accepted. Would you mind giving me permission to edit the documentation?. Thanks. Topics support in camel-hazelcast - Key: CAMEL-7794 URL: https://issues.apache.org/jira/browse/CAMEL-7794 Project: Camel Issue Type: Improvement Components: camel-hazelcast Affects Versions: 2.13.2 Reporter: Juan Jose Vazquez Delgado Assignee: Claus Ibsen Fix For: 2.15.0 As discussed in developer mailing list [1], we needed to add support for Hazelcast distributed topics in Camel. We provide a PR that addresses this [2]. [1] http://camel.465427.n5.nabble.com/Topics-support-in-camel-hazelcast-td5756233.html [2] https://github.com/apache/camel/pull/263 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7794) Topics support in camel-hazelcast
[ https://issues.apache.org/jira/browse/CAMEL-7794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234262#comment-14234262 ] Claus Ibsen commented on CAMEL-7794: Just granted your user karma. Thanks for helping. Topics support in camel-hazelcast - Key: CAMEL-7794 URL: https://issues.apache.org/jira/browse/CAMEL-7794 Project: Camel Issue Type: Improvement Components: camel-hazelcast Affects Versions: 2.13.2 Reporter: Juan Jose Vazquez Delgado Assignee: Claus Ibsen Fix For: 2.15.0 As discussed in developer mailing list [1], we needed to add support for Hazelcast distributed topics in Camel. We provide a PR that addresses this [2]. [1] http://camel.465427.n5.nabble.com/Topics-support-in-camel-hazelcast-td5756233.html [2] https://github.com/apache/camel/pull/263 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8123) Mina2 SSL initiates handshake backwards
[ https://issues.apache.org/jira/browse/CAMEL-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234597#comment-14234597 ] ASF GitHub Bot commented on CAMEL-8123: --- GitHub user peterberkman opened a pull request: https://github.com/apache/camel/pull/349 Camel 2.13.x Correct TLS Handshake fixes: https://issues.apache.org/jira/browse/CAMEL-8123 You can merge this pull request into a Git repository by running: $ git pull https://github.com/peterberkman/camel camel-2.13.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/349.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #349 commit 0fe18488bc237ce1d03b92dc50c0a8e62b6ebdc9 Author: peterberkman pe...@berkmans.net Date: 2014-12-04T20:29:45Z Fixes #CAMEL-8123: Consumer should NOT use ClientMode for TLS commit e446b90315534ca9a6ed8a6a76e5bd3af748f012 Author: peterberkman pe...@berkmans.net Date: 2014-12-04T20:33:02Z Fixes #CAMEL-8123: Producer SHOULD use ClientMode for TLS Mina2 SSL initiates handshake backwards --- Key: CAMEL-8123 URL: https://issues.apache.org/jira/browse/CAMEL-8123 Project: Camel Issue Type: Bug Components: camel-mina2 Affects Versions: 2.13.3, 2.14.0 Reporter: Justin Cozzens The Mina2Consumer and Mina2Producer are configured backwards for SSL handshake initiation. The consumer is trying to initiate the handshake rather than the producer. You can see this by setting up a SSL enabled consuming route and telnet to the port, you will immediately get some data sent from the server to the client rather than the server waiting on the client to initiate the handshake. The issue is Mina2Consumer:160, it is setting UseClientMode to true, it should be false. Mina2Producer line 313 needs to also change to the following: SslFilter filter = new SslFilter(configuration.getSslContextParameters().createSSLContext(), configuration.isAutoStartTls()); filter.setUseClientMode(true); connector.getFilterChain().addFirst(sslFilter, filter); As far as I can tell this has been a bug since this component was introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8123) Mina2 SSL initiates handshake backwards
[ https://issues.apache.org/jira/browse/CAMEL-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234600#comment-14234600 ] ASF GitHub Bot commented on CAMEL-8123: --- GitHub user peterberkman opened a pull request: https://github.com/apache/camel/pull/350 Correctly set client mode for TLS handshakes Fixes CAMEL-8123 - https://issues.apache.org/jira/browse/CAMEL-8123 You can merge this pull request into a Git repository by running: $ git pull https://github.com/peterberkman/camel master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/350.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #350 commit aaf8b632a7ef0e068ebea8a0e98e947e21f1d57e Author: peterberkman pe...@berkmans.net Date: 2014-12-04T20:35:40Z Fixes #CAMEL-8123: Producer SHOULD use ClientMode for TLS commit cf7e22b4592e310901443f5ce9e2cc14a4ebbbcc Author: peterberkman pe...@berkmans.net Date: 2014-12-04T20:36:51Z Fixes #CAMEL-8123: Consumer should NOT use ClientMode for TLS Mina2 SSL initiates handshake backwards --- Key: CAMEL-8123 URL: https://issues.apache.org/jira/browse/CAMEL-8123 Project: Camel Issue Type: Bug Components: camel-mina2 Affects Versions: 2.13.3, 2.14.0 Reporter: Justin Cozzens The Mina2Consumer and Mina2Producer are configured backwards for SSL handshake initiation. The consumer is trying to initiate the handshake rather than the producer. You can see this by setting up a SSL enabled consuming route and telnet to the port, you will immediately get some data sent from the server to the client rather than the server waiting on the client to initiate the handshake. The issue is Mina2Consumer:160, it is setting UseClientMode to true, it should be false. Mina2Producer line 313 needs to also change to the following: SslFilter filter = new SslFilter(configuration.getSslContextParameters().createSSLContext(), configuration.isAutoStartTls()); filter.setUseClientMode(true); connector.getFilterChain().addFirst(sslFilter, filter); As far as I can tell this has been a bug since this component was introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8123) Mina2 SSL initiates handshake backwards
[ https://issues.apache.org/jira/browse/CAMEL-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234697#comment-14234697 ] Peter Berkman commented on CAMEL-8123: -- there was a copy/paste mistake in the above pull requests. Please see comment on the pull request... basically, on the Producer, change acceptor to connector. Mina2 SSL initiates handshake backwards --- Key: CAMEL-8123 URL: https://issues.apache.org/jira/browse/CAMEL-8123 Project: Camel Issue Type: Bug Components: camel-mina2 Affects Versions: 2.13.3, 2.14.0 Reporter: Justin Cozzens The Mina2Consumer and Mina2Producer are configured backwards for SSL handshake initiation. The consumer is trying to initiate the handshake rather than the producer. You can see this by setting up a SSL enabled consuming route and telnet to the port, you will immediately get some data sent from the server to the client rather than the server waiting on the client to initiate the handshake. The issue is Mina2Consumer:160, it is setting UseClientMode to true, it should be false. Mina2Producer line 313 needs to also change to the following: SslFilter filter = new SslFilter(configuration.getSslContextParameters().createSSLContext(), configuration.isAutoStartTls()); filter.setUseClientMode(true); connector.getFilterChain().addFirst(sslFilter, filter); As far as I can tell this has been a bug since this component was introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8123) Mina2 SSL initiates handshake backwards
[ https://issues.apache.org/jira/browse/CAMEL-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-8123: --- Assignee: Willem Jiang Mina2 SSL initiates handshake backwards --- Key: CAMEL-8123 URL: https://issues.apache.org/jira/browse/CAMEL-8123 Project: Camel Issue Type: Bug Components: camel-mina2 Affects Versions: 2.13.3, 2.14.0 Reporter: Justin Cozzens Assignee: Willem Jiang The Mina2Consumer and Mina2Producer are configured backwards for SSL handshake initiation. The consumer is trying to initiate the handshake rather than the producer. You can see this by setting up a SSL enabled consuming route and telnet to the port, you will immediately get some data sent from the server to the client rather than the server waiting on the client to initiate the handshake. The issue is Mina2Consumer:160, it is setting UseClientMode to true, it should be false. Mina2Producer line 313 needs to also change to the following: SslFilter filter = new SslFilter(configuration.getSslContextParameters().createSSLContext(), configuration.isAutoStartTls()); filter.setUseClientMode(true); connector.getFilterChain().addFirst(sslFilter, filter); As far as I can tell this has been a bug since this component was introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8124) Using ServicePool in ConsumerCache
Willem Jiang created CAMEL-8124: --- Summary: Using ServicePool in ConsumerCache Key: CAMEL-8124 URL: https://issues.apache.org/jira/browse/CAMEL-8124 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.15.0 Current ConsumerCache just cache the PollingConsumer in the map, it may cause some trouble if the PollingConsumer is not thread safe. Using the ServicePool to cache the PollingConsumer could help us with that. To workaround this issue, we cannot call the ConsumerTemplate in multithread mode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8122) camel:run using useBlueprint option does not launch camel example project
[
https://issues.apache.org/jira/browse/CAMEL-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234997#comment-14234997
]
Willem Jiang commented on CAMEL-8122:
-
Hi Charles,
I just run the mvn camel:run inside of camel-example-sql-blueprint, I cannot
reproduce the error that you hit.
Can you run mvn clean install -Dtest=false to build the Camel-2.15-SNAPSHOT
first?
Regards,
Willem
camel:run using useBlueprint option does not launch camel example project
---
Key: CAMEL-8122
URL: https://issues.apache.org/jira/browse/CAMEL-8122
Project: Camel
Issue Type: Bug
Components: examples
Affects Versions: 2.15.0
Reporter: Charles Moulliard
When we launch the maven camel:run goal with the camel-example-sql-blueprint,
the camel project is not started and this OSGI Service error is reported.
I suspect that some bundles are missing and not loaded by the PoJoSr
classloader when the project is started/launched by the camel-maven-plugin
See line of code
{code}
package org.apache.camel.maven;
...
public class RunMojo extends AbstractExecMojo {
...
} else if (usingBlueprintMain) {
mainClass = org.apache.camel.test.blueprint.Main;
// must include plugin dependencies for blueprint
extraPluginDependencyArtifactId = camel-test-blueprint;
{code}
Error reported on the console
{code}
Caused by: java.lang.RuntimeException: Gave up waiting for service
(objectClass=org.apache.camel.CamelContext)
[INFO] --- camel-maven-plugin:2.15-SNAPSHOT:run (default-cli) @
camel-example-sql-blueprint ---
[INFO] Using org.apache.camel.test.blueprint.Main to initiate a CamelContext
[INFO] Starting Camel ...
[mel.test.blueprint.Main.main()] MainSupportINFO Apache
Camel 2.15-SNAPSHOT starting
[mel.test.blueprint.Main.main()] Activator INFO Camel
activator starting
[mel.test.blueprint.Main.main()] Activator INFO Camel
activator started
[mel.test.blueprint.Main.main()] BlueprintExtender INFO No
quiesce support is available, so blueprint components will not participate in
quiesce operations
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN Test
bundle headers: Bundle-ManifestVersion=2, Bundle-Name=System Bundle,
Bundle-SymbolicName=de.kalpatec.pojosr.framework, Bundle-Vendor=kalpatec,
Bundle-Version=0.2.1
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.camel.spi.TypeConverterLoader], bundle:
org.apache.camel.camel-core [3], symbolicName: org.apache.camel.camel-core
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.camel.camel-blueprint [2], symbolicName:
org.apache.camel.camel-blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.proxy.ProxyManager], bundle:
org.apache.aries.proxy.impl [19], symbolicName: org.apache.aries.proxy.impl
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ConfigurationAdmin], bundle:
org.apache.felix.configadmin [28], symbolicName: org.apache.felix.configadmin
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.aries.blueprint.NamespaceHandler], bundle:
org.apache.aries.blueprint [17], symbolicName: org.apache.aries.blueprint
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.apache.felix.cm.PersistenceManager], bundle:
org.apache.felix.configadmin [28], symbolicName: org.apache.felix.configadmin
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ManagedServiceFactory], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[mel.test.blueprint.Main.main()] CamelBlueprintHelper WARN
ServiceReference: [org.osgi.service.cm.ConfigurationListener,
org.apache.felix.fileinstall.ArtifactListener,
org.apache.felix.fileinstall.ArtifactInstaller], bundle:
org.apache.felix.fileinstall [29], symbolicName: org.apache.felix.fileinstall
[jira] [Commented] (CAMEL-8042) CxfClientCallBack handleException does not honour exception
[
https://issues.apache.org/jira/browse/CAMEL-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235001#comment-14235001
]
Willem Jiang commented on CAMEL-8042:
-
Hi John,
Could you submit a simple test case for it?
It could save us some time to reproduce the error.
CxfClientCallBack handleException does not honour exception
---
Key: CAMEL-8042
URL: https://issues.apache.org/jira/browse/CAMEL-8042
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.11.2, 2.14.0
Environment: Windows
Reporter: John McKeogh
Assignee: Willem Jiang
Fix For: 2.14.1
Attachments: greeter-corba.wsdl
Hi,
Since Camel 2.11.2, The cxfClientCallBack doesn't seem to be honouring the
exception that it is passed in.
Here is a copy of the HandleException funciton before and after 11.2
2.11.1
public void handleException(MapString, Object ctx, Throwable
ex) {
try {
super.handleException(ctx, ex);
camelExchange.setException(ex);
} finally {
// copy
2.11.2
public void handleException(MapString, Object ctx, Throwable ex) {
try {
super.handleException(ctx, ex);
// need to call the conduitSelector complete method to enable the
fail over feature
ConduitSelector conduitSelector =
cxfExchange.get(ConduitSelector.class);
if (conduitSelector != null) {
conduitSelector.complete(cxfExchange);
ex = cxfExchange.getOutMessage().getContent(Exception.class);
if (ex == null cxfExchange.getInMessage() != null) {
ex =
cxfExchange.getInMessage().getContent(Exception.class);
}
if (ex != null) {
camelExchange.setException(ex);
}
} else {
camelExchange.setException(ex);
}
} finally {
So for our testcase where we have a cxf client calling through camel to a
Corba web service, the exception that the webservice is passing back to camel
is no longer honoured.
I believe this change was introduced by the following jira:
https://issues.apache.org/jira/browse/CAMEL-6609
I have attached the wsdl of the corba web-service.
In the service we are calling PingMe expecting to get back a
PingMeFault_Exception. The exception is set in the cxf corba binding and
reached the exception handler in camel. But the exception is no longer being
sent back to the client. Instead a generic SoapFaultException is reaching the
client.
Cheers,
John.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8001) SmppUtils.isGsm0338Encodeable() called with arbitrary data
[ https://issues.apache.org/jira/browse/CAMEL-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8001. - Resolution: Fixed Merged the patch into camel master, camel-2.14.x and camel-2.13.x branches with thanks to Daniel. SmppUtils.isGsm0338Encodeable() called with arbitrary data -- Key: CAMEL-8001 URL: https://issues.apache.org/jira/browse/CAMEL-8001 Project: Camel Issue Type: Bug Components: camel-smpp Affects Versions: 2.12.2 Environment: n/a Reporter: Daniel Pocock Assignee: Willem Jiang Labels: patch Fix For: 2.13.4, 2.14.1, 2.15.0 Attachments: determineAlphabet_fix.patch The method SmppUtils.isGsm0338Encodeable(byte[]) expects the input data to be Latin1 encoded (or a subset of Latin1, such as ASCII) The method SmppSmCommand.determineAlphabet(Message) prepares an argument by calling String.getBytes(charset) without checking the charset is Latin1 or compatible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8042) CxfClientCallBack handleException does not honour exception
[
https://issues.apache.org/jira/browse/CAMEL-8042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CAMEL-8042:
Fix Version/s: (was: 2.14.1)
2.14.2
CxfClientCallBack handleException does not honour exception
---
Key: CAMEL-8042
URL: https://issues.apache.org/jira/browse/CAMEL-8042
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.11.2, 2.14.0
Environment: Windows
Reporter: John McKeogh
Assignee: Willem Jiang
Fix For: 2.14.2
Attachments: greeter-corba.wsdl
Hi,
Since Camel 2.11.2, The cxfClientCallBack doesn't seem to be honouring the
exception that it is passed in.
Here is a copy of the HandleException funciton before and after 11.2
2.11.1
public void handleException(MapString, Object ctx, Throwable
ex) {
try {
super.handleException(ctx, ex);
camelExchange.setException(ex);
} finally {
// copy
2.11.2
public void handleException(MapString, Object ctx, Throwable ex) {
try {
super.handleException(ctx, ex);
// need to call the conduitSelector complete method to enable the
fail over feature
ConduitSelector conduitSelector =
cxfExchange.get(ConduitSelector.class);
if (conduitSelector != null) {
conduitSelector.complete(cxfExchange);
ex = cxfExchange.getOutMessage().getContent(Exception.class);
if (ex == null cxfExchange.getInMessage() != null) {
ex =
cxfExchange.getInMessage().getContent(Exception.class);
}
if (ex != null) {
camelExchange.setException(ex);
}
} else {
camelExchange.setException(ex);
}
} finally {
So for our testcase where we have a cxf client calling through camel to a
Corba web service, the exception that the webservice is passing back to camel
is no longer honoured.
I believe this change was introduced by the following jira:
https://issues.apache.org/jira/browse/CAMEL-6609
I have attached the wsdl of the corba web-service.
In the service we are calling PingMe expecting to get back a
PingMeFault_Exception. The exception is set in the cxf corba binding and
reached the exception handler in camel. But the exception is no longer being
sent back to the client. Instead a generic SoapFaultException is reaching the
client.
Cheers,
John.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8112) upgrade joda-time version to 2.5
[ https://issues.apache.org/jira/browse/CAMEL-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CAMEL-8112. - Resolution: Fixed Fix Version/s: 2.15.0 2.14.1 upgrade joda-time version to 2.5 Key: CAMEL-8112 URL: https://issues.apache.org/jira/browse/CAMEL-8112 Project: Camel Issue Type: Task Reporter: Freeman Fang Assignee: Freeman Fang Fix For: 2.14.1, 2.15.0 this will affect camel-aws camel-jibx camel-salesforce camel-splunk components -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8092) cxf:producer Matrix Params are missing
[
https://issues.apache.org/jira/browse/CAMEL-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-8092.
-
Resolution: Fixed
Fix Version/s: 2.15.0
2.14.1
2.13.4
Merged the patch into camel master, camel-2.14.x and camel-2.13.x branches with
thanks to Kumarann.
cxf:producer Matrix Params are missing
--
Key: CAMEL-8092
URL: https://issues.apache.org/jira/browse/CAMEL-8092
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.13.3, 2.14.0
Environment: JDK 8. Spring,
Reporter: Kumarann
Assignee: Willem Jiang
Fix For: 2.13.4, 2.14.1, 2.15.0
Attachments: CxfRsProducer.java
In cxfrs component the producer strips away the matrix param.
Steps to reproduce:
Web service proxying configuration (camel-proxy-example).
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=cxfrs://bean://rsServer?bindingStyle=SimpleConsumer/
to uri=cxfrs://bean://rsClient/
/route
/camelContext
But we can see that the Matrix Parameters are completely stripped away in
CxfRsProducer. The SimpleConsumer as the binding style the matrix param will
be sent as header params. But shouldn't the matrix params part of the URL.
ID: 15
Address: http://localhost:8001/test/services/proxyServer/boxing;state=Current
Http-Method: GET
Content-Type:
Headers: {Accept=[application/xml], accept-encoding=[gzip, deflate],
accept-language=[en-us], Authorization=[], connection=[keep-alive],
Content-Length=[0], Content-Type=[null], host=[localhost:8001]}
--
---
ID: 16
Address: http://localhost:29090/MyServer/boxing
Http-Method: GET
Content-Type: */*
Headers: {Accept=[application/xml], state=[Current], user-agent=[xx],
accept-encoding=[gzip, deflate], Content-Length=[0], Authorization=[x],
org.apache.cxf.request.uri=[/services/proxyServer/boxing;state=Current],
host=[localhost:8001], connection=[keep-alive], accept-language=[en-us],
org.apache.cxf.message.Message.PATH_INFO=[/boxing],
org.apache.cxf.request.method=[GET], Content-Type=[*/*]}
I have came across similar issue posted in the past. CAMEL-5405 CXF
Transport loses HTTP Matrix parameters But we are using camel 2.14.0
version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8092) cxf:producer Matrix Params are missing
[
https://issues.apache.org/jira/browse/CAMEL-8092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CAMEL-8092:
Affects Version/s: 2.13.3
cxf:producer Matrix Params are missing
--
Key: CAMEL-8092
URL: https://issues.apache.org/jira/browse/CAMEL-8092
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.13.3, 2.14.0
Environment: JDK 8. Spring,
Reporter: Kumarann
Assignee: Willem Jiang
Fix For: 2.13.4, 2.14.1, 2.15.0
Attachments: CxfRsProducer.java
In cxfrs component the producer strips away the matrix param.
Steps to reproduce:
Web service proxying configuration (camel-proxy-example).
camelContext id=camel xmlns=http://camel.apache.org/schema/spring;
route
from uri=cxfrs://bean://rsServer?bindingStyle=SimpleConsumer/
to uri=cxfrs://bean://rsClient/
/route
/camelContext
But we can see that the Matrix Parameters are completely stripped away in
CxfRsProducer. The SimpleConsumer as the binding style the matrix param will
be sent as header params. But shouldn't the matrix params part of the URL.
ID: 15
Address: http://localhost:8001/test/services/proxyServer/boxing;state=Current
Http-Method: GET
Content-Type:
Headers: {Accept=[application/xml], accept-encoding=[gzip, deflate],
accept-language=[en-us], Authorization=[], connection=[keep-alive],
Content-Length=[0], Content-Type=[null], host=[localhost:8001]}
--
---
ID: 16
Address: http://localhost:29090/MyServer/boxing
Http-Method: GET
Content-Type: */*
Headers: {Accept=[application/xml], state=[Current], user-agent=[xx],
accept-encoding=[gzip, deflate], Content-Length=[0], Authorization=[x],
org.apache.cxf.request.uri=[/services/proxyServer/boxing;state=Current],
host=[localhost:8001], connection=[keep-alive], accept-language=[en-us],
org.apache.cxf.message.Message.PATH_INFO=[/boxing],
org.apache.cxf.request.method=[GET], Content-Type=[*/*]}
I have came across similar issue posted in the past. CAMEL-5405 CXF
Transport loses HTTP Matrix parameters But we are using camel 2.14.0
version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-8121) Infinite Loop Within Camel if the temp file directory is not writable
[ https://issues.apache.org/jira/browse/CAMEL-8121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8121. - Resolution: Fixed Applied the patch into camel master ,camel-2.13.x and camel-2.14.x branches. Infinite Loop Within Camel if the temp file directory is not writable - Key: CAMEL-8121 URL: https://issues.apache.org/jira/browse/CAMEL-8121 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.3, 2.14.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.4, 2.14.1, 2.15.0 If the target 'tmp' directory (specified by java.io.tmpdir) used by Camel, does not have proper privileges, then Camel enters infinite loop. The offending code is found in org.apache.camel.util.FileUtil.createNewTempDir(). We need to check the if the temp file is writable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8123) Mina2 SSL initiates handshake backwards
[ https://issues.apache.org/jira/browse/CAMEL-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8123. - Resolution: Fixed Fix Version/s: 2.15.0 2.14.1 2.13.4 Merged the patch into master, camel-2.13.x and camel-2.14.x branches with thanks to Justin. Mina2 SSL initiates handshake backwards --- Key: CAMEL-8123 URL: https://issues.apache.org/jira/browse/CAMEL-8123 Project: Camel Issue Type: Bug Components: camel-mina2 Affects Versions: 2.13.3, 2.14.0 Reporter: Justin Cozzens Assignee: Willem Jiang Fix For: 2.13.4, 2.14.1, 2.15.0 The Mina2Consumer and Mina2Producer are configured backwards for SSL handshake initiation. The consumer is trying to initiate the handshake rather than the producer. You can see this by setting up a SSL enabled consuming route and telnet to the port, you will immediately get some data sent from the server to the client rather than the server waiting on the client to initiate the handshake. The issue is Mina2Consumer:160, it is setting UseClientMode to true, it should be false. Mina2Producer line 313 needs to also change to the following: SslFilter filter = new SslFilter(configuration.getSslContextParameters().createSSLContext(), configuration.isAutoStartTls()); filter.setUseClientMode(true); connector.getFilterChain().addFirst(sslFilter, filter); As far as I can tell this has been a bug since this component was introduced. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7945) SMPP connector as consumer stops camel context
[ https://issues.apache.org/jira/browse/CAMEL-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235156#comment-14235156 ] Tomas Hanus commented on CAMEL-7945: Hi Claus, if you want i can do that. Although on a project we use other solutions based upon health check service SMPP connector as consumer stops camel context -- Key: CAMEL-7945 URL: https://issues.apache.org/jira/browse/CAMEL-7945 Project: Camel Issue Type: Improvement Components: camel-smpp Affects Versions: 2.13.2 Reporter: Tomas Hanus Fix For: Future I try to use SMPP component as producer and consumer to send SMS and PUSH SMS (MMS) to SMSC/receive delivery notifications or SMS from mobile devices. But still if SMSC is down camel context will shut down, and also all other context, so camel cannot start up. Affect version is camel 2.13.2 and only consumer. Producer is OK and parameter lazySessionCreation=true works well, but not for consumer. Any idea how to solve that? Probably it has to do with CAMEL-3853 issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8105) AWS-SQS - support for redrivePolicy inside SQSEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-8105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-8105. - Resolution: Fixed AWS-SQS - support for redrivePolicy inside SQSEndpoint -- Key: CAMEL-8105 URL: https://issues.apache.org/jira/browse/CAMEL-8105 Project: Camel Issue Type: Improvement Components: camel-aws Reporter: Rufus Nash Assignee: Willem Jiang Priority: Minor Labels: easyfix, patch Fix For: 2.15.0 Attachments: camel-aws-redrivePolicyPatch.patch Support currently doesn't exist for setting the redrivePolicy through the endpoint URI inside SQSEndpoint. This means it is not possible to setup any dead letter queue logic in AWS SQS without doing so by hand through the front end. I'll attach a patch which adds the field to the SqsConfiguration and the handling of that logic inside the SqsEndpoint. As well as extended the basic tests on proving they get set correctly by the SqsComponentConfigurationTest Regards Rufus -- This message was sent by Atlassian JIRA (v6.3.4#6332)
