[jira] [Commented] (CAMEL-7921) The soapAction HTTP header is not correctly set when running the CXF client in POJO mode using Camel
[
https://issues.apache.org/jira/browse/CAMEL-7921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621852#comment-14621852
]
Claus Ibsen commented on CAMEL-7921:
I wonder if its when using wsdlURL the SoapAction is inside that wsdl file and
that would require logic to parse it and find it to set it.
And any chance to try with latest code, its been a long time since this was
reported?
> The soapAction HTTP header is not correctly set when running the CXF client
> in POJO mode using Camel
>
>
> Key: CAMEL-7921
> URL: https://issues.apache.org/jira/browse/CAMEL-7921
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.12.3, 2.12.4, 2.13.2, 2.14.0
>Reporter: Ton Swieb
> Attachments: soapActionTest.zip
>
>
> The soapAction HTTP header is not correctly set when running the CXF client
> in POJO mode using Camel.
> The root cause seems to be that the service name from the generated service
> class differs from the service name in the WSDL.
> For me it is unclear if this should be an issue with the cxf-codegen-plugin
> or with the Camel CXF component. When running the CXF client without Camel
> then the soapAction HTTP header is correctly set and the issue does not
> occur. So that's why I first report the bug with Camel.
> Possible workarounds I found are:
> 1) Explicitly specifying the correct serviceName as CXF endpoint attribute.
> 2) Explicitly setting the soapAction header in the Camel route prior to
> calling the CXF endpoint.
> Both workarounds are not desirable, because they are easily forgotten and CXF
> does not throw an exception when you do. According to the basic profile v1.0
> the soapAction HTTP header must match the value in the WSDL and receiving
> SOAP servers may throw a SOAP Fault if it doesn't. Some SOAP servers do throw
> an exception when the soapAction HTTP header is invalid. Resulting in
> communication failures between some SOAP client/server combinations.
> I created a test project to verify the above behaviour with the following
> tests:
> 1) CXF in PAYLOAD with Camel. => OK
> 2) CXF in POJO mode without Camel => OK
> 3) CXF in POJO mode with Camel => *NOT OK*
> 4) CXF in POJO mode with service name set => OK
> 5) CXF in POJO mode with soapAction set => OK
> I run the test project with multiple combinations of Camel and CXF. The
> following combinations I have tried:
> 1) Camel 2.12.3 and CXF 2.7.10 (Apache Servicemix 5.0.0 setup)
> 2) Camel 2.12.4 and CXF 2.7.11 (Apache Servicemix 5.0.5 setup)
> 3) Camel 2.13.2 and CXF 2.7.11 (Apache Servicemix 5.1.3 and 5.3.0 setup)
> 4) Camel 2.14.0 and CXF 3.0.1
> In the example project the mismatch occurs between an annotation in the
> generated service class:
> {code}
> @WebService(targetNamespace = "http://finalist.nl/ai/";, name =
> "ICamelCxfTestService")
> {code}
> and the definition of the service name in the WSDL:
> {code}
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7809) Quartz PollConsumerScheduler in a cluster tries to create duplicate triggers, fails
[
https://issues.apache.org/jira/browse/CAMEL-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621854#comment-14621854
]
Claus Ibsen commented on CAMEL-7809:
Can you try with latest code, we have done changes since and this ticket is a
bit old now
> Quartz PollConsumerScheduler in a cluster tries to create duplicate triggers,
> fails
> ---
>
> Key: CAMEL-7809
> URL: https://issues.apache.org/jira/browse/CAMEL-7809
> Project: Camel
> Issue Type: Improvement
> Components: camel-quartz2
>Affects Versions: 2.13.1
> Environment: identical CamelContexts deployed to each node in a
> cluster
> Quartz 2.2.1 with JDBC JobStore and synchronization via DB
>Reporter: Steffen Ryll
> Attachments: camel-quartz2_clustering_20190912.patch
>
>
> I tested the patch developed in CAMEL-7663 and ran into another issue that
> prevents the CamelContext from starting up. The setup is the same as
> described in CAMEL-7663.
> Upon startup I get following exception from Quartz on at least one cluster
> node:
> {code}
> 13:23:36|INFO |component.quartz2.QuartzComponent|[ACTIVE] ExecuteThread: '3'
> for queue: 'weblogic.kernel.Default (self-tuning)'|Shutting down scheduler.
> (will wait for all jobs to complete first.)
> 13:23:36|INFO |quartz.core.QuartzScheduler|[ACTIVE] ExecuteThread: '3' for
> queue: 'weblogic.kernel.Default (self-tuning)'|Scheduler
> IPP_Integration_Scheduler-emerald-integration-web_$_fra...1410348212901
> shutting down.
> 13:23:36|INFO |quartz.core.QuartzScheduler|[ACTIVE] ExecuteThread: '3' for
> queue: 'weblogic.kernel.Default (self-tuning)'|Scheduler
> IPP_Integration_Scheduler-emerald-integration-web_$_fra...1410348212901
> paused.
> 13:23:36|INFO |quartz.core.QuartzScheduler|[ACTIVE] ExecuteThread: '3' for
> queue: 'weblogic.kernel.Default (self-tuning)'|Scheduler unregistered from
> name
> 'quartz:type=QuartzScheduler,name=IPP_Integration_Scheduler-emerald-integration-web,instance=fra...1410348212901'
> in the local MBeanServer.
> 2014-09-10-13:23:36|INFO |quartz.core.QuartzScheduler|[ACTIVE] ExecuteThread:
> '3' for queue: 'weblogic.kernel.Default (self-tuning)'|Scheduler
> IPP_Integration_Scheduler-emerald-integration-web_$_fra...1410348212901
> shutdown complete.
> 13:23:36|ERROR|component.servletlistener.CamelServletContextListener|[ACTIVE]
> ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'|Error
> starting CamelContext.
> org.quartz.ObjectAlreadyExistsException: Unable to store Trigger with name:
> 'scheduler.fax.in' and group: 'QuartzScheduledPollConsumerScheduler', because
> one already exists with this identification.
> at
> org.quartz.impl.jdbcjobstore.JobStoreSupport.storeTrigger(JobStoreSupport.java:1179)
> at
> org.quartz.impl.jdbcjobstore.JobStoreSupport$2.executeVoid(JobStoreSupport.java:1063)
> at
> org.quartz.impl.jdbcjobstore.JobStoreSupport$VoidTransactionCallback.execute(JobStoreSupport.java:3703)
> at
> org.quartz.impl.jdbcjobstore.JobStoreSupport$VoidTransactionCallback.execute(JobStoreSupport.java:3701)
> at
> org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3787)
> at
> org.quartz.impl.jdbcjobstore.JobStoreTX.executeInLock(JobStoreTX.java:93)
> at
> org.quartz.impl.jdbcjobstore.JobStoreSupport.storeJobAndTrigger(JobStoreSupport.java:1058)
> at org.quartz.core.QuartzScheduler.scheduleJob(QuartzScheduler.java:886)
> at org.quartz.impl.StdScheduler.scheduleJob(StdScheduler.java:249)
> at
> org.apache.camel.pollconsumer.quartz2.QuartzScheduledPollConsumerScheduler.doStart(QuartzScheduledPollConsumerScheduler.java:187)
> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> at
> org.apache.camel.util.ServiceHelper.startService(ServiceHelper.java:74)
> at
> org.apache.camel.impl.ScheduledPollConsumer.doStart(ScheduledPollConsumer.java:499)
> at
> org.apache.camel.component.file.GenericFileConsumer.doStart(GenericFileConsumer.java:640)
> at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
> at
> org.apache.camel.impl.DefaultCamelContext.startService(DefaultCamelContext.java:2042)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRouteConsumers(DefaultCamelContext.java:2336)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartRouteConsumers(DefaultCamelContext.java:2272)
> at
> org.apache.camel.impl.DefaultCamelContext.safelyStartRouteServices(DefaultCamelContext.java:2202)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartOrResumeRoutes(DefaultCamelContext.java:1981)
> at
> org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamel
[jira] [Resolved] (CAMEL-3557) EIP pattern documentation - Each pattern having examples should have at least one Java DSL and XML counterpart
[ https://issues.apache.org/jira/browse/CAMEL-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-3557. Resolution: Later > EIP pattern documentation - Each pattern having examples should have at least > one Java DSL and XML counterpart > -- > > Key: CAMEL-3557 > URL: https://issues.apache.org/jira/browse/CAMEL-3557 > Project: Camel > Issue Type: Improvement > Components: documentation >Affects Versions: 2.5.0 >Reporter: Claus Ibsen > Fix For: Future > > > Check the EIP patterns > http://camel.apache.org/enterprise-integration-patterns.html > And add missing Java DSL and/or XML examples. Apparently XML end users aren't > good at using the XML Schema to known how to configure an EIP pattern. > So we should improve the documentation and add examples for both DSL flavors. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6937) BeanManager cannot be retrieved when camel cdi is deployed in Karaf
[
https://issues.apache.org/jira/browse/CAMEL-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6937:
---
Fix Version/s: (was: Future)
2.16
> BeanManager cannot be retrieved when camel cdi is deployed in Karaf
> ---
>
> Key: CAMEL-6937
> URL: https://issues.apache.org/jira/browse/CAMEL-6937
> Project: Camel
> Issue Type: New Feature
> Components: camel-cdi, osgi
>Reporter: Charles Moulliard
> Fix For: 2.16
>
>
> When Camel CDI is deployed in Karaf using Pax CDI 0.6.0-SNAPSHOT, Weld 2.0 &
> CDI 1.1 Spec then the camel cdi extension raises this exception as the
> BeanManager cannot retrieved
> Code must be refactorised :
> {code}
> Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with
> 1 exceptions:
> Exception 0 :
> java.lang.IllegalStateException: No
> org.apache.deltaspike.core.api.provider.BeanManagerProvider in place! Please
> ensure that you configured the CDI implementation of your choice properly. If
> your setup is correct, please clear all caches and compiled artifacts.
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.getInstance(BeanManagerProvider.java:133)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:473)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:117)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:100)
> at
> org.apache.camel.cdi.internal.CamelExtension.getCamelContext(CamelExtension.java:331)
> at
> org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:226)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meat
> 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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
> at
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:119)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
> at
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
> at
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
> at
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvva:63)
> at
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
> at
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
> at
> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:429)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:81)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.createBeanManager(WeldCdiContainer.java:114)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.access$000(WeldCdiContainer.java:55)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:93)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.doStart(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.cdi.spi.AbstractCdiContainer.start(AbstractCdiContainer.java:88)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.createContainer(CdiExtender.java:128)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:86)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:44)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)
> at
[jira] [Resolved] (CAMEL-7789) camel-servlet - Should register in OSGi so karaf web:list show the servlet url
[
https://issues.apache.org/jira/browse/CAMEL-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7789.
Resolution: Won't Fix
I guess web:list is for WAR apps
> camel-servlet - Should register in OSGi so karaf web:list show the servlet url
> --
>
> Key: CAMEL-7789
> URL: https://issues.apache.org/jira/browse/CAMEL-7789
> Project: Camel
> Issue Type: Improvement
> Components: camel-servlet, karaf, osgi
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: Future
>
>
> Install the camel-example-servlet-rest-blueprint in Karaf.
> Do a web:list which shows nothing.
> {code}
> karaf@root> web:list
>ID State Level Web-ContextPath Name
> karaf@root>
> {code}
> It should show the url of the camel-servlet (the alias url)
> {code}
>
>
>init-method="register"
> destroy-method="unregister">
> value="/camel-example-servlet-rest-blueprint/rest"/>
>
>
>
>class="org.apache.camel.component.servlet.CamelHttpTransportServlet"/>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6937) BeanManager cannot be retrieved when camel cdi is deployed in Karaf
[
https://issues.apache.org/jira/browse/CAMEL-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6937:
---
Issue Type: Improvement (was: New Feature)
> BeanManager cannot be retrieved when camel cdi is deployed in Karaf
> ---
>
> Key: CAMEL-6937
> URL: https://issues.apache.org/jira/browse/CAMEL-6937
> Project: Camel
> Issue Type: Improvement
> Components: camel-cdi, osgi
>Reporter: Charles Moulliard
> Fix For: 2.16
>
>
> When Camel CDI is deployed in Karaf using Pax CDI 0.6.0-SNAPSHOT, Weld 2.0 &
> CDI 1.1 Spec then the camel cdi extension raises this exception as the
> BeanManager cannot retrieved
> Code must be refactorised :
> {code}
> Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with
> 1 exceptions:
> Exception 0 :
> java.lang.IllegalStateException: No
> org.apache.deltaspike.core.api.provider.BeanManagerProvider in place! Please
> ensure that you configured the CDI implementation of your choice properly. If
> your setup is correct, please clear all caches and compiled artifacts.
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.getInstance(BeanManagerProvider.java:133)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:473)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:117)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:100)
> at
> org.apache.camel.cdi.internal.CamelExtension.getCamelContext(CamelExtension.java:331)
> at
> org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:226)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meat
> 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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
> at
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:119)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
> at
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
> at
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
> at
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvva:63)
> at
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
> at
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
> at
> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:429)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:81)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.createBeanManager(WeldCdiContainer.java:114)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.access$000(WeldCdiContainer.java:55)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:93)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.doStart(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.cdi.spi.AbstractCdiContainer.start(AbstractCdiContainer.java:88)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.createContainer(CdiExtender.java:128)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:86)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:44)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)
> at
> org.apach
[jira] [Commented] (CAMEL-6937) BeanManager cannot be retrieved when camel cdi is deployed in Karaf
[
https://issues.apache.org/jira/browse/CAMEL-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621858#comment-14621858
]
Claus Ibsen commented on CAMEL-6937:
We should try to get camel-cdi working in OSGi - it may already do.
> BeanManager cannot be retrieved when camel cdi is deployed in Karaf
> ---
>
> Key: CAMEL-6937
> URL: https://issues.apache.org/jira/browse/CAMEL-6937
> Project: Camel
> Issue Type: Improvement
> Components: camel-cdi, osgi
>Reporter: Charles Moulliard
> Fix For: 2.16
>
>
> When Camel CDI is deployed in Karaf using Pax CDI 0.6.0-SNAPSHOT, Weld 2.0 &
> CDI 1.1 Spec then the camel cdi extension raises this exception as the
> BeanManager cannot retrieved
> Code must be refactorised :
> {code}
> Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with
> 1 exceptions:
> Exception 0 :
> java.lang.IllegalStateException: No
> org.apache.deltaspike.core.api.provider.BeanManagerProvider in place! Please
> ensure that you configured the CDI implementation of your choice properly. If
> your setup is correct, please clear all caches and compiled artifacts.
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.getInstance(BeanManagerProvider.java:133)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:473)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:117)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:100)
> at
> org.apache.camel.cdi.internal.CamelExtension.getCamelContext(CamelExtension.java:331)
> at
> org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:226)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meat
> 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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
> at
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:119)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
> at
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
> at
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
> at
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvva:63)
> at
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
> at
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
> at
> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:429)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:81)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.createBeanManager(WeldCdiContainer.java:114)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.access$000(WeldCdiContainer.java:55)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:93)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.doStart(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.cdi.spi.AbstractCdiContainer.start(AbstractCdiContainer.java:88)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.createContainer(CdiExtender.java:128)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:86)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:44)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.Bundl
[jira] [Updated] (CAMEL-6937) BeanManager cannot be retrieved when camel cdi is deployed in Karaf
[
https://issues.apache.org/jira/browse/CAMEL-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6937:
---
Assignee: (was: Charles Moulliard)
> BeanManager cannot be retrieved when camel cdi is deployed in Karaf
> ---
>
> Key: CAMEL-6937
> URL: https://issues.apache.org/jira/browse/CAMEL-6937
> Project: Camel
> Issue Type: New Feature
> Components: camel-cdi, osgi
>Reporter: Charles Moulliard
> Fix For: 2.16
>
>
> When Camel CDI is deployed in Karaf using Pax CDI 0.6.0-SNAPSHOT, Weld 2.0 &
> CDI 1.1 Spec then the camel cdi extension raises this exception as the
> BeanManager cannot retrieved
> Code must be refactorised :
> {code}
> Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with
> 1 exceptions:
> Exception 0 :
> java.lang.IllegalStateException: No
> org.apache.deltaspike.core.api.provider.BeanManagerProvider in place! Please
> ensure that you configured the CDI implementation of your choice properly. If
> your setup is correct, please clear all caches and compiled artifacts.
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.getInstance(BeanManagerProvider.java:133)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:473)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:117)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:100)
> at
> org.apache.camel.cdi.internal.CamelExtension.getCamelContext(CamelExtension.java:331)
> at
> org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:226)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meat
> 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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
> at
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:119)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
> at
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
> at
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
> at
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvva:63)
> at
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
> at
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
> at
> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:429)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:81)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.createBeanManager(WeldCdiContainer.java:114)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.access$000(WeldCdiContainer.java:55)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:93)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.doStart(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.cdi.spi.AbstractCdiContainer.start(AbstractCdiContainer.java:88)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.createContainer(CdiExtender.java:128)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:86)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:44)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)
> at
> org.apache.fel
[jira] [Updated] (CAMEL-6937) BeanManager cannot be retrieved when camel cdi is deployed in Karaf
[
https://issues.apache.org/jira/browse/CAMEL-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6937:
---
Component/s: osgi
> BeanManager cannot be retrieved when camel cdi is deployed in Karaf
> ---
>
> Key: CAMEL-6937
> URL: https://issues.apache.org/jira/browse/CAMEL-6937
> Project: Camel
> Issue Type: New Feature
> Components: camel-cdi, osgi
>Reporter: Charles Moulliard
> Fix For: 2.16
>
>
> When Camel CDI is deployed in Karaf using Pax CDI 0.6.0-SNAPSHOT, Weld 2.0 &
> CDI 1.1 Spec then the camel cdi extension raises this exception as the
> BeanManager cannot retrieved
> Code must be refactorised :
> {code}
> Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with
> 1 exceptions:
> Exception 0 :
> java.lang.IllegalStateException: No
> org.apache.deltaspike.core.api.provider.BeanManagerProvider in place! Please
> ensure that you configured the CDI implementation of your choice properly. If
> your setup is correct, please clear all caches and compiled artifacts.
> at
> org.apache.deltaspike.core.api.provider.BeanManagerProvider.getInstance(BeanManagerProvider.java:133)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getBeanManager(BeanProvider.java:473)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:117)
> at
> org.apache.deltaspike.core.api.provider.BeanProvider.getContextualReference(BeanProvider.java:100)
> at
> org.apache.camel.cdi.internal.CamelExtension.getCamelContext(CamelExtension.java:331)
> at
> org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:226)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meat
> 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.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
> at
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:119)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
> at
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
> at
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
> at
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvva:63)
> at
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
> at
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
> at
> org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:429)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:81)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.createBeanManager(WeldCdiContainer.java:114)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.access$000(WeldCdiContainer.java:55)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:93)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer$1.call(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.swissbox.core.ContextClassLoaderUtils.doWithClassLoader(ContextClassLoaderUtils.java:60)
> at
> org.ops4j.pax.cdi.weld.impl.WeldCdiContainer.doStart(WeldCdiContainer.java:89)
> at
> org.ops4j.pax.cdi.spi.AbstractCdiContainer.start(AbstractCdiContainer.java:88)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.createContainer(CdiExtender.java:128)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:86)
> at
> org.ops4j.pax.cdi.extender.impl.CdiExtender.addingBundle(CdiExtender.java:44)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)
> at
> org.apache.felix.framework.util.Eve
[jira] [Updated] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7500: --- Fix Version/s: (was: Future) 2.16.0 > Concurrent modification of exchange during retry after netty TCP failure > leads to futher processing of failed messages > -- > > Key: CAMEL-7500 > URL: https://issues.apache.org/jira/browse/CAMEL-7500 > Project: Camel > Issue Type: Bug > Components: camel-netty >Affects Versions: 2.13.1 >Reporter: Bob Browning >Assignee: Claus Ibsen > Fix For: 2.16.0 > > Attachments: NettyRedeliveryTest.java > > > When a exception occurs on a netty TCP channel such as ChanelClosedException > then there are two invocations of the producer callback. > If there is a redelivery handler configured this causes either two threads to > be added to the scheduled thread-pool which then compete or in the more > common case the first invocation adds the redelivery thread but in doing so > clears the exception from the exchange such that when the subsequent callback > invocation occurs it see's the event as a success and continues routing of > the exchange. > Note this also seems to be a cause of negative inflight messages on the route. > The first callback invocation occurs in the ChannelFutureListener which is > the usual case. > The second callback invocation which comes from the ClientChannelHandler > registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14621958#comment-14621958 ] Claus Ibsen commented on CAMEL-7500: Okay so it seems its because both netty producer detects the exception and also the client handler, and therefore we do 2 x callback. Thanks Bob for this test case it helps dig down the problem, although it was a bit complicated to track down. > Concurrent modification of exchange during retry after netty TCP failure > leads to futher processing of failed messages > -- > > Key: CAMEL-7500 > URL: https://issues.apache.org/jira/browse/CAMEL-7500 > Project: Camel > Issue Type: Bug > Components: camel-netty >Affects Versions: 2.13.1 >Reporter: Bob Browning >Assignee: Claus Ibsen > Fix For: 2.16.0 > > Attachments: NettyRedeliveryTest.java > > > When a exception occurs on a netty TCP channel such as ChanelClosedException > then there are two invocations of the producer callback. > If there is a redelivery handler configured this causes either two threads to > be added to the scheduled thread-pool which then compete or in the more > common case the first invocation adds the redelivery thread but in doing so > clears the exception from the exchange such that when the subsequent callback > invocation occurs it see's the event as a success and continues routing of > the exchange. > Note this also seems to be a cause of negative inflight messages on the route. > The first callback invocation occurs in the ChannelFutureListener which is > the usual case. > The second callback invocation which comes from the ClientChannelHandler > registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-7500: -- Assignee: Claus Ibsen (was: Willem Jiang) > Concurrent modification of exchange during retry after netty TCP failure > leads to futher processing of failed messages > -- > > Key: CAMEL-7500 > URL: https://issues.apache.org/jira/browse/CAMEL-7500 > Project: Camel > Issue Type: Bug > Components: camel-netty >Affects Versions: 2.13.1 >Reporter: Bob Browning >Assignee: Claus Ibsen > Fix For: 2.16.0 > > Attachments: NettyRedeliveryTest.java > > > When a exception occurs on a netty TCP channel such as ChanelClosedException > then there are two invocations of the producer callback. > If there is a redelivery handler configured this causes either two threads to > be added to the scheduled thread-pool which then compete or in the more > common case the first invocation adds the redelivery thread but in doing so > clears the exception from the exchange such that when the subsequent callback > invocation occurs it see's the event as a success and continues routing of > the exchange. > Note this also seems to be a cause of negative inflight messages on the route. > The first callback invocation occurs in the ChannelFutureListener which is > the usual case. > The second callback invocation which comes from the ClientChannelHandler > registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7500) Concurrent modification of exchange during retry after netty TCP failure leads to futher processing of failed messages
[ https://issues.apache.org/jira/browse/CAMEL-7500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7500. Resolution: Fixed Fix Version/s: 2.15.3 > Concurrent modification of exchange during retry after netty TCP failure > leads to futher processing of failed messages > -- > > Key: CAMEL-7500 > URL: https://issues.apache.org/jira/browse/CAMEL-7500 > Project: Camel > Issue Type: Bug > Components: camel-netty >Affects Versions: 2.13.1 >Reporter: Bob Browning >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.3 > > Attachments: NettyRedeliveryTest.java > > > When a exception occurs on a netty TCP channel such as ChanelClosedException > then there are two invocations of the producer callback. > If there is a redelivery handler configured this causes either two threads to > be added to the scheduled thread-pool which then compete or in the more > common case the first invocation adds the redelivery thread but in doing so > clears the exception from the exchange such that when the subsequent callback > invocation occurs it see's the event as a success and continues routing of > the exchange. > Note this also seems to be a cause of negative inflight messages on the route. > The first callback invocation occurs in the ChannelFutureListener which is > the usual case. > The second callback invocation which comes from the ClientChannelHandler > registered in the DefaultClientPipelineFactory used by the NettyProducer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7332) camel-sql - Should have dynamic import so jdbc driver can be loaded
[ https://issues.apache.org/jira/browse/CAMEL-7332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7332. Resolution: Won't Fix > camel-sql - Should have dynamic import so jdbc driver can be loaded > --- > > Key: CAMEL-7332 > URL: https://issues.apache.org/jira/browse/CAMEL-7332 > Project: Camel > Issue Type: Improvement > Components: camel-sql >Affects Versions: 2.12.3 >Reporter: Claus Ibsen >Assignee: Willem Jiang > Fix For: Future > > > If you use OSGi blueprint and use camel-sql, to setup a jdbc driver then it > cannot load it from a blueprint xml file. > But if you use spring-dm it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-5723) camel-jaxb: partClass and partNamespace dynamically set by header
[ https://issues.apache.org/jira/browse/CAMEL-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5723: --- Assignee: (was: Grzegorz Grzybek) > camel-jaxb: partClass and partNamespace dynamically set by header > - > > Key: CAMEL-5723 > URL: https://issues.apache.org/jira/browse/CAMEL-5723 > Project: Camel > Issue Type: New Feature > Components: camel-jaxb >Reporter: Raúl Kripalani > Fix For: Future > > > The Camel JAXB Data Format allows to specify a partClass and partNamespace on > the data format configuration. > If you have many cases of partial marshalling or unmarshalling, you're forced > to configure as many data formats as part classes you'll ever need to handle. > Aside from being inconvenient, it makes route initialisation pretty > inefficient because a JAXBContext is created per data format, performing a > full scan and reflection of the package each time. Slows down route startup > considerably. > Enhance the Camel JAXB Data Format so that it's capable of doing partial > unmarshalling at runtime based on message headers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-5104) [GSoC 2012] Alerts support
[ https://issues.apache.org/jira/browse/CAMEL-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5104. Resolution: Won't Fix > [GSoC 2012] Alerts support > -- > > Key: CAMEL-5104 > URL: https://issues.apache.org/jira/browse/CAMEL-5104 > Project: Camel > Issue Type: New Feature > Components: camel-core, camel-snmp, jmx >Reporter: Michał Warecki >Priority: Minor > Labels: gsoc2012 > Fix For: Future > > Original Estimate: 2,016h > Remaining Estimate: 2,016h > > I think this functionality can help Camel meet some of the requirements of > mission-critical systems. > Alerts are kind of events which may indicate threat to the proper functioning > of the integration platform such as: > - specified thread pool reaches a specified threshold ratio > (http://camel.apache.org/threading-model.html), > - low memory (i.e. 70% Perm Gen is used), > - specified URL location is invalid (i.e. returns specified code), > - specified JMX attribute has specifies value (it really can be a point to > custom alert guard), > - specified exception type occurs (i.e. IOException may be caused by lack of > disk space), > - route did not finish its execution within specified period of time, > - some specified expression based on headers values. > Alerts should send predefined notifications (configured by standard Camel > components like SMTP or SNMP). Additionally, it should be possible to set > severity level of alert. > See nabble: > http://camel.465427.n5.nabble.com/DISCUSS-Camel-Alerts-td5497221.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7193) Assertions are applied an extra, unnecessary time after an assertion period
[
https://issues.apache.org/jira/browse/CAMEL-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7193:
---
Fix Version/s: (was: Future)
2.16
> Assertions are applied an extra, unnecessary time after an assertion period
> ---
>
> Key: CAMEL-7193
> URL: https://issues.apache.org/jira/browse/CAMEL-7193
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Anders Rabo Thorbeck
>Priority: Minor
> Fix For: 2.16
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{org.apache.camel.component.mock.MockEndpoint.expectedMessagesMatches(Predicate...)}}
> is implemented in such a way that, if the test at hand is run with an assert
> period, then an assertion will be run once before the assert period, but will
> then be run twice more (when it only needs to run once more) after the
> assertion period is up.
> This is because the {{run()}} method of the
> {{org.apache.camel.component.mock.AssertionClause}} created in
> {{expectedMessagesMatches(Predicate...)}} calls
> {{AssertionClause.addPredicate(Predicate)}}, which has not been implemented
> as an [idempotent|http://en.wiktionary.org/wiki/idempotence] function.
> Therefore, when the assertion is run before the assert period, the
> {{Predicate}} is added to the {{AssertionClause}} once, and when the
> assertion is run again _after_ the assert period, the same {{Predicate}} is
> added again to the same {{AssertionClause}}, and so it is executed one more
> time than necessary.
> This can be fixed by making the method
> {{AssertionClause.addPredicate(Predicate)}} idempotent. Suggestions for doing
> so are:
> * to change the type of
> {{org.apache.camel.component.mock.AssertionClause.predicates}} from
> {{List}} to {{Set}} ({{java.util.LinkedHashSet}} will
> preserve insertion order), or
> * to add a containment check in {{AssertionClause.addPredicate(Predicate)}},
> before adding the {{Predicate}} to the list.
> I am not sure whether this will work with equality checking of anonymous
> Predicate classes with themselves.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7193) Assertions are applied an extra, unnecessary time after an assertion period
[
https://issues.apache.org/jira/browse/CAMEL-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-7193:
--
Assignee: Claus Ibsen
> Assertions are applied an extra, unnecessary time after an assertion period
> ---
>
> Key: CAMEL-7193
> URL: https://issues.apache.org/jira/browse/CAMEL-7193
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Anders Rabo Thorbeck
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{org.apache.camel.component.mock.MockEndpoint.expectedMessagesMatches(Predicate...)}}
> is implemented in such a way that, if the test at hand is run with an assert
> period, then an assertion will be run once before the assert period, but will
> then be run twice more (when it only needs to run once more) after the
> assertion period is up.
> This is because the {{run()}} method of the
> {{org.apache.camel.component.mock.AssertionClause}} created in
> {{expectedMessagesMatches(Predicate...)}} calls
> {{AssertionClause.addPredicate(Predicate)}}, which has not been implemented
> as an [idempotent|http://en.wiktionary.org/wiki/idempotence] function.
> Therefore, when the assertion is run before the assert period, the
> {{Predicate}} is added to the {{AssertionClause}} once, and when the
> assertion is run again _after_ the assert period, the same {{Predicate}} is
> added again to the same {{AssertionClause}}, and so it is executed one more
> time than necessary.
> This can be fixed by making the method
> {{AssertionClause.addPredicate(Predicate)}} idempotent. Suggestions for doing
> so are:
> * to change the type of
> {{org.apache.camel.component.mock.AssertionClause.predicates}} from
> {{List}} to {{Set}} ({{java.util.LinkedHashSet}} will
> preserve insertion order), or
> * to add a containment check in {{AssertionClause.addPredicate(Predicate)}},
> before adding the {{Predicate}} to the list.
> I am not sure whether this will work with equality checking of anonymous
> Predicate classes with themselves.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8893) Upgrade to CXF 3.1.x
[ https://issues.apache.org/jira/browse/CAMEL-8893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622037#comment-14622037 ] Akitoshi Yoshida commented on CAMEL-8893: - I committed the change. The change has been verified with the camel-cxf unit tests and some camel-cxf osgi tests using the camel-cxf karaf feature as is (i.e., pulling cxf 3.1.1 transitively on a fresh karaf instance) and on an instance where cxf 3.0.5 is pre-installed. > Upgrade to CXF 3.1.x > > > Key: CAMEL-8893 > URL: https://issues.apache.org/jira/browse/CAMEL-8893 > Project: Camel > Issue Type: Improvement > Components: camel-cxf >Reporter: Claus Ibsen >Assignee: Akitoshi Yoshida > Fix For: 2.16.0 > > > We should upgrade to CXF 3.1.x as it support jetty 9, and we should make > jetty 9 as the default jetty component. > Jetty 8 is EOL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7193) Assertions are applied an extra, unnecessary time after an assertion period
[
https://issues.apache.org/jira/browse/CAMEL-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7193.
Resolution: Fixed
Thanks for the suggestion
> Assertions are applied an extra, unnecessary time after an assertion period
> ---
>
> Key: CAMEL-7193
> URL: https://issues.apache.org/jira/browse/CAMEL-7193
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Anders Rabo Thorbeck
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.16
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {{org.apache.camel.component.mock.MockEndpoint.expectedMessagesMatches(Predicate...)}}
> is implemented in such a way that, if the test at hand is run with an assert
> period, then an assertion will be run once before the assert period, but will
> then be run twice more (when it only needs to run once more) after the
> assertion period is up.
> This is because the {{run()}} method of the
> {{org.apache.camel.component.mock.AssertionClause}} created in
> {{expectedMessagesMatches(Predicate...)}} calls
> {{AssertionClause.addPredicate(Predicate)}}, which has not been implemented
> as an [idempotent|http://en.wiktionary.org/wiki/idempotence] function.
> Therefore, when the assertion is run before the assert period, the
> {{Predicate}} is added to the {{AssertionClause}} once, and when the
> assertion is run again _after_ the assert period, the same {{Predicate}} is
> added again to the same {{AssertionClause}}, and so it is executed one more
> time than necessary.
> This can be fixed by making the method
> {{AssertionClause.addPredicate(Predicate)}} idempotent. Suggestions for doing
> so are:
> * to change the type of
> {{org.apache.camel.component.mock.AssertionClause.predicates}} from
> {{List}} to {{Set}} ({{java.util.LinkedHashSet}} will
> preserve insertion order), or
> * to add a containment check in {{AssertionClause.addPredicate(Predicate)}},
> before adding the {{Predicate}} to the list.
> I am not sure whether this will work with equality checking of anonymous
> Predicate classes with themselves.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-6336) camel cdi uses postconstruct to inject in cdi beans
[ https://issues.apache.org/jira/browse/CAMEL-6336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6336. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: (was: Future) 2.16 Thanks for the suggestion > camel cdi uses postconstruct to inject in cdi beans > --- > > Key: CAMEL-6336 > URL: https://issues.apache.org/jira/browse/CAMEL-6336 > Project: Camel > Issue Type: Bug > Components: camel-cdi >Affects Versions: 2.11.0 >Reporter: Romain Manni-Bucau >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16 > > > org.apache.camel.cdi.internal.CamelExtension#onInjectionTarget uses > InjectionTarget#postConstruct instead of inject() to inject camel injections. > That's not really consistent since postconstruct is done once injections are > done because they can be used in post construct methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CAMEL-7469) Make CamelBlueprintTestSupport tests more predictable
[
https://issues.apache.org/jira/browse/CAMEL-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek reopened CAMEL-7469:
-
Reopening - there's still one issue
> Make CamelBlueprintTestSupport tests more predictable
> -
>
> Key: CAMEL-7469
> URL: https://issues.apache.org/jira/browse/CAMEL-7469
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
>Affects Versions: 2.13.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
> Fix For: 2.12.4, 2.13.2, 2.14.0
>
>
> Currently the tests which override
> {{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#useOverridePropertiesWithConfigAdmin}}
> or
> {{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#loadConfigAdminConfigurationFile}}
> have race issue, because changing configuration leads to reload of Blueprint
> Container.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-6338) camel-cdi shouldn't use deltapsike bean manager provider in the CamelExtension
[ https://issues.apache.org/jira/browse/CAMEL-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6338. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: (was: Future) 2.16 Thanks for the suggestion > camel-cdi shouldn't use deltapsike bean manager provider in the CamelExtension > -- > > Key: CAMEL-6338 > URL: https://issues.apache.org/jira/browse/CAMEL-6338 > Project: Camel > Issue Type: Improvement > Components: camel-cdi >Reporter: Romain Manni-Bucau >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16 > > > In an cdi extension the bean manager is injected so camel cdi shouldn't use > deltaspike for it. > A nice side effect of it will be it will remove WARNING > The only trick it will need will be to give > org.apache.camel.cdi.CdiBeanRegistry the bean manager to use. A thread local > or delegate (registry.getDelegate()) falling back to DS if null should be > fine. It just needs to be resetted after extension startup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6976) camel-itest-cdi - Fails due recent changes in camel-cdi etc
[ https://issues.apache.org/jira/browse/CAMEL-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6976: --- Fix Version/s: (was: Future) 2.16 > camel-itest-cdi - Fails due recent changes in camel-cdi etc > --- > > Key: CAMEL-6976 > URL: https://issues.apache.org/jira/browse/CAMEL-6976 > Project: Camel > Issue Type: Task > Components: camel-cdi, tests >Affects Versions: 2.13.0 >Reporter: Claus Ibsen > Fix For: 2.16 > > > I noticed this error on my master branch today > Running org.apache.camel.itest.cdi.IntegrationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.821 sec <<< > FAILURE! - in org.apache.camel.itest.cdi.IntegrationTest > org.apache.camel.itest.cdi.IntegrationTest Time elapsed: 2.82 sec <<< ERROR! > I suspect its due some of the recent changes in camel-cdi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-6976) camel-itest-cdi - Fails due recent changes in camel-cdi etc
[ https://issues.apache.org/jira/browse/CAMEL-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6976: -- Assignee: Claus Ibsen > camel-itest-cdi - Fails due recent changes in camel-cdi etc > --- > > Key: CAMEL-6976 > URL: https://issues.apache.org/jira/browse/CAMEL-6976 > Project: Camel > Issue Type: Task > Components: camel-cdi, tests >Affects Versions: 2.13.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16 > > > I noticed this error on my master branch today > Running org.apache.camel.itest.cdi.IntegrationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.821 sec <<< > FAILURE! - in org.apache.camel.itest.cdi.IntegrationTest > org.apache.camel.itest.cdi.IntegrationTest Time elapsed: 2.82 sec <<< ERROR! > I suspect its due some of the recent changes in camel-cdi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6976) camel-itest-cdi - Fails due recent changes in camel-cdi etc
[ https://issues.apache.org/jira/browse/CAMEL-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6976. Resolution: Fixed > camel-itest-cdi - Fails due recent changes in camel-cdi etc > --- > > Key: CAMEL-6976 > URL: https://issues.apache.org/jira/browse/CAMEL-6976 > Project: Camel > Issue Type: Task > Components: camel-cdi, tests >Affects Versions: 2.13.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16 > > > I noticed this error on my master branch today > Running org.apache.camel.itest.cdi.IntegrationTest > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.821 sec <<< > FAILURE! - in org.apache.camel.itest.cdi.IntegrationTest > org.apache.camel.itest.cdi.IntegrationTest Time elapsed: 2.82 sec <<< ERROR! > I suspect its due some of the recent changes in camel-cdi. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers
Grzegorz Grzybek created CAMEL-8948:
---
Summary: CamelBlueprintTestSupport tests have issues with
namespace handlers
Key: CAMEL-8948
URL: https://issues.apache.org/jira/browse/CAMEL-8948
Project: Camel
Issue Type: Improvement
Components: camel-blueprint
Affects Versions: 2.13.1
Reporter: Grzegorz Grzybek
Assignee: Grzegorz Grzybek
Fix For: 2.12.4, 2.13.2, 2.14.0
Currently the tests which override
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#useOverridePropertiesWithConfigAdmin}}
or
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#loadConfigAdminConfigurationFile}}
have race issue, because changing configuration leads to reload of Blueprint
Container.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-7469) Make CamelBlueprintTestSupport tests more predictable
[
https://issues.apache.org/jira/browse/CAMEL-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated CAMEL-7469:
Comment: was deleted
(was: Reopening - there's still one issue)
> Make CamelBlueprintTestSupport tests more predictable
> -
>
> Key: CAMEL-7469
> URL: https://issues.apache.org/jira/browse/CAMEL-7469
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
>Affects Versions: 2.13.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
> Fix For: 2.12.4, 2.13.2, 2.14.0
>
>
> Currently the tests which override
> {{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#useOverridePropertiesWithConfigAdmin}}
> or
> {{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#loadConfigAdminConfigurationFile}}
> have race issue, because changing configuration leads to reload of Blueprint
> Container.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7469) Make CamelBlueprintTestSupport tests more predictable
[
https://issues.apache.org/jira/browse/CAMEL-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek resolved CAMEL-7469.
-
Resolution: Fixed
> Make CamelBlueprintTestSupport tests more predictable
> -
>
> Key: CAMEL-7469
> URL: https://issues.apache.org/jira/browse/CAMEL-7469
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
>Affects Versions: 2.13.1
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
> Fix For: 2.14.0, 2.13.2, 2.12.4
>
>
> Currently the tests which override
> {{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#useOverridePropertiesWithConfigAdmin}}
> or
> {{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#loadConfigAdminConfigurationFile}}
> have race issue, because changing configuration leads to reload of Blueprint
> Container.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers
[ https://issues.apache.org/jira/browse/CAMEL-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek updated CAMEL-8948: Affects Version/s: (was: 2.13.1) 2.15.2 > CamelBlueprintTestSupport tests have issues with namespace handlers > --- > > Key: CAMEL-8948 > URL: https://issues.apache.org/jira/browse/CAMEL-8948 > Project: Camel > Issue Type: Improvement > Components: camel-blueprint >Affects Versions: 2.15.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > Fix For: 2.16.0, 2.15.3 > > > Camel blueprint tests have problems with missing namespace handlers due to > fragile NS code in aries-blueprint. > This should be fixed with blueprint-core 1.4.4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers
[
https://issues.apache.org/jira/browse/CAMEL-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated CAMEL-8948:
Description:
Camel blueprint tests have problems with missing namespace handlers due to
fragile NS code in aries-blueprint.
This should be fixed with blueprint-core 1.4.4.
was:Currently the tests which override
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#useOverridePropertiesWithConfigAdmin}}
or
{{org.apache.camel.test.blueprint.CamelBlueprintTestSupport#loadConfigAdminConfigurationFile}}
have race issue, because changing configuration leads to reload of Blueprint
Container.
> CamelBlueprintTestSupport tests have issues with namespace handlers
> ---
>
> Key: CAMEL-8948
> URL: https://issues.apache.org/jira/browse/CAMEL-8948
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint
>Affects Versions: 2.15.2
>Reporter: Grzegorz Grzybek
>Assignee: Grzegorz Grzybek
> Fix For: 2.16.0, 2.15.3
>
>
> Camel blueprint tests have problems with missing namespace handlers due to
> fragile NS code in aries-blueprint.
> This should be fixed with blueprint-core 1.4.4.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers
[ https://issues.apache.org/jira/browse/CAMEL-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek updated CAMEL-8948: Fix Version/s: (was: 2.13.2) (was: 2.12.4) (was: 2.14.0) 2.15.3 2.16.0 > CamelBlueprintTestSupport tests have issues with namespace handlers > --- > > Key: CAMEL-8948 > URL: https://issues.apache.org/jira/browse/CAMEL-8948 > Project: Camel > Issue Type: Improvement > Components: camel-blueprint >Affects Versions: 2.15.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > Fix For: 2.16.0, 2.15.3 > > > Camel blueprint tests have problems with missing namespace handlers due to > fragile NS code in aries-blueprint. > This should be fixed with blueprint-core 1.4.4. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-3126) Add osgi tests in camel-itest-osgi for every camel component
[ https://issues.apache.org/jira/browse/CAMEL-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-3126. Resolution: Won't Fix > Add osgi tests in camel-itest-osgi for every camel component > > > Key: CAMEL-3126 > URL: https://issues.apache.org/jira/browse/CAMEL-3126 > Project: Camel > Issue Type: Task > Components: osgi >Affects Versions: 2.4.0 >Reporter: Claus Ibsen > Fix For: Future > > > Some components isn't tested in itest for osgi. They are only tested in > camel-itest-karaf that the feature can be loaded. However we should add route > tests which uses the component in question. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-4707) Features descriptor should define the namespace
[ https://issues.apache.org/jira/browse/CAMEL-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-4707. Resolution: Implemented Fix Version/s: (was: 3.0.0) 2.16 > Features descriptor should define the namespace > --- > > Key: CAMEL-4707 > URL: https://issues.apache.org/jira/browse/CAMEL-4707 > Project: Camel > Issue Type: Improvement > Components: karaf >Affects Versions: 2.8.3, 2.9.0 >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré > Fix For: 2.16 > > > In future Karaf 3.0, the features XML validation will be required. It means > that the features XML descriptor should define the right namespace. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-4707) Features descriptor should define the namespace
[
https://issues.apache.org/jira/browse/CAMEL-4707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622178#comment-14622178
]
Claus Ibsen commented on CAMEL-4707:
We have namespace today and testing works
http://karaf.apache.org/xmlns/features/v1.0.0";
name='camel-${project.version}'>
> Features descriptor should define the namespace
> ---
>
> Key: CAMEL-4707
> URL: https://issues.apache.org/jira/browse/CAMEL-4707
> Project: Camel
> Issue Type: Improvement
> Components: karaf
>Affects Versions: 2.8.3, 2.9.0
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
> Fix For: 2.16
>
>
> In future Karaf 3.0, the features XML validation will be required. It means
> that the features XML descriptor should define the right namespace.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6943) CamelContext should log the settings which could change the configure of Camel runtime
[ https://issues.apache.org/jira/browse/CAMEL-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6943: --- Issue Type: Improvement (was: New Feature) > CamelContext should log the settings which could change the configure of > Camel runtime > -- > > Key: CAMEL-6943 > URL: https://issues.apache.org/jira/browse/CAMEL-6943 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: Future > > > Some of camel components uses the System properties to do configuration, it > could be useful for the users to know about them if we can log these setting > when starting the camel context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6943) CamelContext should log the settings which could change the configure of Camel runtime
[ https://issues.apache.org/jira/browse/CAMEL-6943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6943: --- Priority: Minor (was: Major) > CamelContext should log the settings which could change the configure of > Camel runtime > -- > > Key: CAMEL-6943 > URL: https://issues.apache.org/jira/browse/CAMEL-6943 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Willem Jiang >Assignee: Willem Jiang >Priority: Minor > Fix For: Future > > > Some of camel components uses the System properties to do configuration, it > could be useful for the users to know about them if we can log these setting > when starting the camel context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6944) Add exchangeId in the toString() method of the DefaultExchange
[ https://issues.apache.org/jira/browse/CAMEL-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6944. Resolution: Fixed Assignee: Claus Ibsen (was: Jean-Baptiste Onofré) Fix Version/s: (was: Future) 2.16 > Add exchangeId in the toString() method of the DefaultExchange > -- > > Key: CAMEL-6944 > URL: https://issues.apache.org/jira/browse/CAMEL-6944 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Jean-Baptiste Onofré >Assignee: Claus Ibsen > Fix For: 2.16 > > > In order for the users to easily trace the exchange, it would be great that > the toString() method of the DefaultExchange displays the exchangeId. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7152) HttpProducer loses response data (specifically which headers where returned)
[ https://issues.apache.org/jira/browse/CAMEL-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622189#comment-14622189 ] Claus Ibsen commented on CAMEL-7152: Contributions is welcome, we could have an option preserveHeaders=true as default, and then the user can turn this off as suggested. > HttpProducer loses response data (specifically which headers where returned) > > > Key: CAMEL-7152 > URL: https://issues.apache.org/jira/browse/CAMEL-7152 > Project: Camel > Issue Type: New Feature > Components: camel-http, camel-http4 >Affects Versions: 2.12.2 >Reporter: Yannick Menager >Priority: Minor > Fix For: Future > > > HTTPProducer is currently copying all the older headers from IN onto the OUT. > This means that after doing an HTTP call, there is *no way* to know which > headers where returned by destination server, and which were there originally. > In my case this is disastrous because I need to do an HMAC which include all > headers :( > Please add an HttpEndpoint Options which allows to disable that behaviour and > not copy any old headers from IN. (and yes in that case the original headers > would get lost, but then the developer can just preserve whatever he needs by > storing the data in the exchange properties) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7152) HttpProducer loses response data (specifically which headers where returned)
[ https://issues.apache.org/jira/browse/CAMEL-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7152: --- Fix Version/s: Future > HttpProducer loses response data (specifically which headers where returned) > > > Key: CAMEL-7152 > URL: https://issues.apache.org/jira/browse/CAMEL-7152 > Project: Camel > Issue Type: New Feature > Components: camel-http, camel-http4 >Affects Versions: 2.12.2 >Reporter: Yannick Menager >Priority: Minor > Fix For: Future > > > HTTPProducer is currently copying all the older headers from IN onto the OUT. > This means that after doing an HTTP call, there is *no way* to know which > headers where returned by destination server, and which were there originally. > In my case this is disastrous because I need to do an HMAC which include all > headers :( > Please add an HttpEndpoint Options which allows to disable that behaviour and > not copy any old headers from IN. (and yes in that case the original headers > would get lost, but then the developer can just preserve whatever he needs by > storing the data in the exchange properties) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7152) HttpProducer loses response data (specifically which headers where returned)
[ https://issues.apache.org/jira/browse/CAMEL-7152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7152: --- Priority: Minor (was: Major) > HttpProducer loses response data (specifically which headers where returned) > > > Key: CAMEL-7152 > URL: https://issues.apache.org/jira/browse/CAMEL-7152 > Project: Camel > Issue Type: New Feature > Components: camel-http, camel-http4 >Affects Versions: 2.12.2 >Reporter: Yannick Menager >Priority: Minor > Fix For: Future > > > HTTPProducer is currently copying all the older headers from IN onto the OUT. > This means that after doing an HTTP call, there is *no way* to know which > headers where returned by destination server, and which were there originally. > In my case this is disastrous because I need to do an HMAC which include all > headers :( > Please add an HttpEndpoint Options which allows to disable that behaviour and > not copy any old headers from IN. (and yes in that case the original headers > would get lost, but then the developer can just preserve whatever he needs by > storing the data in the exchange properties) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7153) Timer component - Allow to change timer trigger at runtime using JMX
[ https://issues.apache.org/jira/browse/CAMEL-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7153. Resolution: Won't Fix > Timer component - Allow to change timer trigger at runtime using JMX > > > Key: CAMEL-7153 > URL: https://issues.apache.org/jira/browse/CAMEL-7153 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.12.0 >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > We should make it easier to reconfigure timer routes so people can change at > runtime when a timer task triggers next time. > See SO > http://stackoverflow.com/questions/21309081/camel-runtime-timer-change -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-4576) Make exception throwing as flexible in XML as in Java DSL
[
https://issues.apache.org/jira/browse/CAMEL-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4576:
---
Fix Version/s: (was: 3.0.0)
2.16
> Make exception throwing as flexible in XML as in Java DSL
> -
>
> Key: CAMEL-4576
> URL: https://issues.apache.org/jira/browse/CAMEL-4576
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-core, camel-spring
>Affects Versions: 2.8.1
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: exception, throwException, xml
> Fix For: 2.16
>
>
> When throwing exceptions there are more options in the java DSL (one has full
> control) than in the XML where you can only reference an exception instance.
> It would be useful to be able to construct the exception and throw it, so
> that one could add messages to it - preferably like:
> {noformat}
> throwException class="someEx" message="someProblem ${body}
> ${in.header.someHeader}
> {noformat}
> Reference: http://camel.apache.org/exception-clause.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-4576) Make exception throwing as flexible in XML as in Java DSL
[
https://issues.apache.org/jira/browse/CAMEL-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-4576:
--
Assignee: Claus Ibsen
> Make exception throwing as flexible in XML as in Java DSL
> -
>
> Key: CAMEL-4576
> URL: https://issues.apache.org/jira/browse/CAMEL-4576
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-core, camel-spring
>Affects Versions: 2.8.1
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: exception, throwException, xml
> Fix For: 2.16
>
>
> When throwing exceptions there are more options in the java DSL (one has full
> control) than in the XML where you can only reference an exception instance.
> It would be useful to be able to construct the exception and throw it, so
> that one could add messages to it - preferably like:
> {noformat}
> throwException class="someEx" message="someProblem ${body}
> ${in.header.someHeader}
> {noformat}
> Reference: http://camel.apache.org/exception-clause.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8948) CamelBlueprintTestSupport tests have issues with namespace handlers
[ https://issues.apache.org/jira/browse/CAMEL-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Grzybek updated CAMEL-8948: Description: Camel blueprint tests have problems with missing namespace handlers due to fragile NS code in aries-blueprint. This should be fixed with blueprint-core 1.4.4. There are also situations, where camel context is started before its blueprint container is really CREATED. was: Camel blueprint tests have problems with missing namespace handlers due to fragile NS code in aries-blueprint. This should be fixed with blueprint-core 1.4.4. > CamelBlueprintTestSupport tests have issues with namespace handlers > --- > > Key: CAMEL-8948 > URL: https://issues.apache.org/jira/browse/CAMEL-8948 > Project: Camel > Issue Type: Improvement > Components: camel-blueprint >Affects Versions: 2.15.2 >Reporter: Grzegorz Grzybek >Assignee: Grzegorz Grzybek > Fix For: 2.16.0, 2.15.3 > > > Camel blueprint tests have problems with missing namespace handlers due to > fragile NS code in aries-blueprint. > This should be fixed with blueprint-core 1.4.4. > There are also situations, where camel context is started before its > blueprint container is really CREATED. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-4576) Make exception throwing as flexible in XML as in Java DSL
[
https://issues.apache.org/jira/browse/CAMEL-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622230#comment-14622230
]
Claus Ibsen commented on CAMEL-4576:
You can now do (also possible in java dsl)
{code:xml}
http://camel.apache.org/schema/spring";>
{code}
> Make exception throwing as flexible in XML as in Java DSL
> -
>
> Key: CAMEL-4576
> URL: https://issues.apache.org/jira/browse/CAMEL-4576
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-core, camel-spring
>Affects Versions: 2.8.1
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: exception, throwException, xml
> Fix For: 2.16
>
>
> When throwing exceptions there are more options in the java DSL (one has full
> control) than in the XML where you can only reference an exception instance.
> It would be useful to be able to construct the exception and throw it, so
> that one could add messages to it - preferably like:
> {noformat}
> throwException class="someEx" message="someProblem ${body}
> ${in.header.someHeader}
> {noformat}
> Reference: http://camel.apache.org/exception-clause.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-4576) Make exception throwing as flexible in XML as in Java DSL
[
https://issues.apache.org/jira/browse/CAMEL-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-4576.
Resolution: Fixed
> Make exception throwing as flexible in XML as in Java DSL
> -
>
> Key: CAMEL-4576
> URL: https://issues.apache.org/jira/browse/CAMEL-4576
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-core, camel-spring
>Affects Versions: 2.8.1
> Environment: N/A
>Reporter: David J. M. Karlsen
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: exception, throwException, xml
> Fix For: 2.16
>
>
> When throwing exceptions there are more options in the java DSL (one has full
> control) than in the XML where you can only reference an exception instance.
> It would be useful to be able to construct the exception and throw it, so
> that one could add messages to it - preferably like:
> {noformat}
> throwException class="someEx" message="someProblem ${body}
> ${in.header.someHeader}
> {noformat}
> Reference: http://camel.apache.org/exception-clause.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-5911) seda/vm - Add option to discard message if no active consumers
[ https://issues.apache.org/jira/browse/CAMEL-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-5911: -- Assignee: Claus Ibsen > seda/vm - Add option to discard message if no active consumers > -- > > Key: CAMEL-5911 > URL: https://issues.apache.org/jira/browse/CAMEL-5911 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: Future > > > When using seda/vm queues, you may have 0..n active consumers. > There may be use-cases where you want to discard a message if there is no > current active consumers to process the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-5911) seda/vm - Add option to discard message if no active consumers
[ https://issues.apache.org/jira/browse/CAMEL-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-5911: --- Fix Version/s: (was: Future) 2.16 > seda/vm - Add option to discard message if no active consumers > -- > > Key: CAMEL-5911 > URL: https://issues.apache.org/jira/browse/CAMEL-5911 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16 > > > When using seda/vm queues, you may have 0..n active consumers. > There may be use-cases where you want to discard a message if there is no > current active consumers to process the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8949) Netty 3 component spins on receiving TCP RST
Jonathan Anstey created CAMEL-8949:
--
Summary: Netty 3 component spins on receiving TCP RST
Key: CAMEL-8949
URL: https://issues.apache.org/jira/browse/CAMEL-8949
Project: Camel
Issue Type: Bug
Affects Versions: 2.15.2
Reporter: Jonathan Anstey
Assignee: Jonathan Anstey
Fix For: 2.16.0, 2.15.3
When receiving a TCP RST, Netty 3 goes into a deep recursion identified by a
stack something like:
{code}
[Camel Thread #1 - NettyServerTCPWorker] WARN
org.apache.camel.component.netty.http.NettyHttpConsumer -
HttpServerChannelHandler is not found as attachment to handle exception, send
404 back to the client.
java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
at
org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
at org.jboss.netty.channel.Channels.write(Channels.java:725)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
at org.jboss.netty.channel.Channels.write(Channels.java:704)
at org.jboss.netty.channel.Channels.write(Channels.java:671)
at
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at
org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.exceptionCaught(HttpServerMultiplexChannelHandler.java:142)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChannelUpstreamHandler.java:153)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:377)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
at
org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:525)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:291)
at
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
at
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
at org.jboss.netty.channel.Channels.write(Channels.java:725)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71)
at
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
at
org.jboss.netty.channel.DefaultChannelPipeli
[jira] [Resolved] (CAMEL-8949) Netty 3 component spins on receiving TCP RST
[
https://issues.apache.org/jira/browse/CAMEL-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Anstey resolved CAMEL-8949.
Resolution: Fixed
http://git-wip-us.apache.org/repos/asf/camel/commit/821bddf5
> Netty 3 component spins on receiving TCP RST
>
>
> Key: CAMEL-8949
> URL: https://issues.apache.org/jira/browse/CAMEL-8949
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.15.2
>Reporter: Jonathan Anstey
>Assignee: Jonathan Anstey
> Fix For: 2.16.0, 2.15.3
>
>
> When receiving a TCP RST, Netty 3 goes into a deep recursion identified by a
> stack something like:
> {code}
> [Camel Thread #1 - NettyServerTCPWorker] WARN
> org.apache.camel.component.netty.http.NettyHttpConsumer -
> HttpServerChannelHandler is not found as attachment to handle exception, send
> 404 back to the client.
> java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
> at
> org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
> at
> org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
> at
> org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
> at org.jboss.netty.channel.Channels.write(Channels.java:725)
> at
> org.jboss.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71)
> at
> org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
> at org.jboss.netty.channel.Channels.write(Channels.java:704)
> at org.jboss.netty.channel.Channels.write(Channels.java:671)
> at
> org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
> at
> org.apache.camel.component.netty.http.handlers.HttpServerMultiplexChannelHandler.exceptionCaught(HttpServerMultiplexChannelHandler.java:142)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.exceptionCaught(SimpleChannelUpstreamHandler.java:153)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at
> org.jboss.netty.handler.codec.frame.FrameDecoder.exceptionCaught(FrameDecoder.java:377)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:112)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
> at
> org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:525)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:291)
> at
> org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:146)
> at
> org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:99)
> at
> org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:36)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779)
>
[jira] [Resolved] (CAMEL-5911) seda/vm - Add option to discard message if no active consumers
[ https://issues.apache.org/jira/browse/CAMEL-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-5911. Resolution: Fixed > seda/vm - Add option to discard message if no active consumers > -- > > Key: CAMEL-5911 > URL: https://issues.apache.org/jira/browse/CAMEL-5911 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16 > > > When using seda/vm queues, you may have 0..n active consumers. > There may be use-cases where you want to discard a message if there is no > current active consumers to process the message. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8950) Injected Quartz2 scheduler doesn't have access to CamelContext in jobs
Jonathan Anstey created CAMEL-8950: -- Summary: Injected Quartz2 scheduler doesn't have access to CamelContext in jobs Key: CAMEL-8950 URL: https://issues.apache.org/jira/browse/CAMEL-8950 Project: Camel Issue Type: Bug Affects Versions: 2.15.2 Reporter: Jonathan Anstey Assignee: Jonathan Anstey Fix For: 2.16.0, 2.15.3 Currently if you inject a scheduler the CamelContext won't be available for jobs to access. When the scheduler is created automatically, the context is added to the quartz scheduler context so the jobs can access it: quartzContext.put(QuartzConstants.QUARTZ_CAMEL_CONTEXT + "-" + camelContextName, getCamelContext()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8950) Injected Quartz2 scheduler doesn't have access to CamelContext in jobs
[ https://issues.apache.org/jira/browse/CAMEL-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Anstey resolved CAMEL-8950. Resolution: Fixed https://git1-us-west.apache.org/repos/asf?p=camel.git;a=commit;h=4fc73b4cde1b0f6e8d57e4a9c32377e118dcb69e > Injected Quartz2 scheduler doesn't have access to CamelContext in jobs > -- > > Key: CAMEL-8950 > URL: https://issues.apache.org/jira/browse/CAMEL-8950 > Project: Camel > Issue Type: Bug >Affects Versions: 2.15.2 >Reporter: Jonathan Anstey >Assignee: Jonathan Anstey > Fix For: 2.16.0, 2.15.3 > > > Currently if you inject a scheduler the CamelContext won't be available for > jobs to access. When the scheduler is created automatically, the context is > added to the quartz scheduler context so the jobs can access it: > quartzContext.put(QuartzConstants.QUARTZ_CAMEL_CONTEXT + "-" + > camelContextName, getCamelContext()); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8951) RecipientList with RAW parameter do not work
Claus Ibsen created CAMEL-8951: -- Summary: RecipientList with RAW parameter do not work Key: CAMEL-8951 URL: https://issues.apache.org/jira/browse/CAMEL-8951 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.2 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.16.0, 2.15.3 See nabble http://camel.465427.n5.nabble.com/java-net-URISyntaxException-using-recipientList-tp5769103.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8941) Restlet supports binary files only with media type application/octet-stream
[
https://issues.apache.org/jira/browse/CAMEL-8941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622491#comment-14622491
]
Anton Koscejev commented on CAMEL-8941:
---
I've created PR 558: https://github.com/apache/camel/pull/558
> Restlet supports binary files only with media type application/octet-stream
>
>
> Key: CAMEL-8941
> URL: https://issues.apache.org/jira/browse/CAMEL-8941
> Project: Camel
> Issue Type: Improvement
> Components: camel-restlet
>Affects Versions: 2.15.2
>Reporter: Anton Koscejev
> Fix For: 2.16.0
>
>
> The camel-restlet component populates Camel Exchange from Restlet Response
> via DefaultRestletBinding. However, it only properly reads binary contents if
> media type is "application/octet-stream". In all other cases it reads
> contents as String, even if contents are binary. For example, if the contents
> are of type "audio/wave" - a normal .wav file returned by a REST service -
> they would be read as a String, which results in an unplayable file.
> See code extract:
> {code}
> if (mediaType != null &&
> mediaType.equals(MediaType.APPLICATION_OCTET_STREAM)) {
> exchange.getOut().setBody(response.getEntity().getStream());
> } else if (response.getEntity() instanceof Representation) {
> Representation representationDecoded = new
> DecodeRepresentation(response.getEntity());
> exchange.getOut().setBody(representationDecoded.getText());
> } else {
> // get content text by default
> String text = response.getEntity().getText();
> LOG.debug("Populate exchange from Restlet response: {}", text);
> exchange.getOut().setBody(text);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-4596) enrich and pollEnrich should accept an expression for dynamic uris
[
https://issues.apache.org/jira/browse/CAMEL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622791#comment-14622791
]
Andy Fedotov commented on CAMEL-4596:
-
This is must-have feature, I hope it will be implemented ASAP and as it should.
Meanwhile it can be implemented with custom message Processor. I've created and
using one.
https://gist.github.com/afedotov/c9565ac5a53a45662d30
Example:
{code:java}
String enrichURI =
"file:path/to/basedir/${date:now:MMdd}?fileName=index.xml";
from("direct:start")
.process(DynamicPollEnricher.from(simple(enrichURI)))
.to("bean:messageProcessor")
.to("mock:result");
{code}
More example:
- Scan directory recursively for *.pdf files and read each one
- Enrich it with .xml file that located next to .pdf file and has same name
- Pass two files together for processing
{code:java}
String startURI =
"file:path/to/docs?recursive=true&antInclude=**/*.pdf&noop=true&readLock=none";
String enrichURI =
"file:${header.CamelFileParent}?fileName=${file:onlyname.noext}.xml&noop=true&readLock=none";
from(startURI)
.process(DynamicPollEnricher.from(simple(enrichURI)))
.to("bean:processDocument")
.to("mock:result");
{code}
For accessing message list body inside processor beans there are helper methods:
{code:java}
InputStream pdfFileStream = DynamicPollEnricher.getMessageBody(inputExchange,
0, InputStream.class);
Document metadata = DynamicPollEnricher.getMessageBody(inputExchange, 1,
Document.class);
{code}
> enrich and pollEnrich should accept an expression for dynamic uris
> --
>
> Key: CAMEL-4596
> URL: https://issues.apache.org/jira/browse/CAMEL-4596
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: 3.0.0
>
>
> We should consider using an expression for uri's for the enrich and
> pollEnrich EIP's so we can poll from a dynamic computed endpoint.
> However it will break API as currently the uri is mandatory.
> It's a bit the same problem with to EIP which is also static uri. However for
> to EIP we have recipientList which is the dynamic to.
> So we need a similar dynamic for enrich and pollEnrich.
> This also solves the problem with that people wan't to provide details from
> the current exchange in the endpoint uri. We have a ticket for that.
> eg enrich("file:inbox?fileName=${header.nameToPickUp}")
> So if we can do it using an expression it could be
> .enrich().simple("file:inbox?fileName=${header.nameToPickUp}")
> See nabble
> http://camel.465427.n5.nabble.com/pollEnrich-consumer-with-selector-tp4939908p4939908.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8578) camel-http - May double encode uri when using HTTP_URI or HTTP_QUERY headers
[ https://issues.apache.org/jira/browse/CAMEL-8578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622849#comment-14622849 ] ASF GitHub Bot commented on CAMEL-8578: --- GitHub user snurmine opened a pull request: https://github.com/apache/camel/pull/559 CAMEL-8578 - May double encode uri when using HTTP_URI or HTTP_QUERY … Fix for issue https://issues.apache.org/jira/browse/CAMEL-8578. camel-http uses class UnsafeUriCharactersEncoder in HttpHelper#createURI. UnsafeUriCharactersEncoder explicitly doesn't encode character >= 128. If url = "http://www.google.com/search?hl=en&q=%E2%82%AC"; is as parameter for HttpHelper#createURI, then: $URI uri = new URI(url); Here uri now contains queryString in unencoded form, which means, that also euro-character is in encoded form. http://www.fileformat.info/info/unicode/char/20aC/index.htm. Later in same method $// need to encode query string $queryString = UnsafeUriCharactersEncoder.encodeHttpURI(queryString); Method UnsafeUriCharactersEncoder#encodeHttpURI does not encode euro character back to encoded form. Fix was to add UTF-8 encoding support into UnsafeUriCharactersEncoder#encodeHttpURI according to https://tools.ietf.org/html/rfc3986. You can merge this pull request into a Git repository by running: $ git pull https://github.com/snurmine/camel CAMEL-8578 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/559.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 #559 commit 7f186ddabf6808968c730eab03247352ef686b07 Author: Sami Nurminen Date: 2015-07-10T20:04:51Z CAMEL-8578 - May double encode uri when using HTTP_URI or HTTP_QUERY headers > camel-http - May double encode uri when using HTTP_URI or HTTP_QUERY headers > > > Key: CAMEL-8578 > URL: https://issues.apache.org/jira/browse/CAMEL-8578 > Project: Camel > Issue Type: Bug > Components: camel-http >Affects Versions: 2.14.1 >Reporter: Claus Ibsen > Fix For: Future > > > See nabble > http://camel.465427.n5.nabble.com/Apache-Camel-decodes-HTTP-query-params-and-httpclient-fails-with-Invalid-query-exception-tp5764794p5764843.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8893) Upgrade to CXF 3.1.x
[ https://issues.apache.org/jira/browse/CAMEL-8893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akitoshi Yoshida resolved CAMEL-8893. - Resolution: Fixed > Upgrade to CXF 3.1.x > > > Key: CAMEL-8893 > URL: https://issues.apache.org/jira/browse/CAMEL-8893 > Project: Camel > Issue Type: Improvement > Components: camel-cxf >Reporter: Claus Ibsen >Assignee: Akitoshi Yoshida > Fix For: 2.16.0 > > > We should upgrade to CXF 3.1.x as it support jetty 9, and we should make > jetty 9 as the default jetty component. > Jetty 8 is EOL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8951) RecipientList with RAW parameter do not work
[ https://issues.apache.org/jira/browse/CAMEL-8951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-8951. Resolution: Fixed > RecipientList with RAW parameter do not work > > > Key: CAMEL-8951 > URL: https://issues.apache.org/jira/browse/CAMEL-8951 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.15.2 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16.0, 2.15.3 > > > See nabble > http://camel.465427.n5.nabble.com/java-net-URISyntaxException-using-recipientList-tp5769103.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7054) CamelNetty - No way to get ChannelGroup
[ https://issues.apache.org/jira/browse/CAMEL-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7054: --- Estimated Complexity: Novice (was: Unknown) > CamelNetty - No way to get ChannelGroup > --- > > Key: CAMEL-7054 > URL: https://issues.apache.org/jira/browse/CAMEL-7054 > Project: Camel > Issue Type: Improvement > Components: camel-netty >Affects Versions: 2.12.0, 2.12.1, 2.12.2 >Reporter: Matthew McMahon >Priority: Trivial > Fix For: Future > > > My use case is that I need to create a custom ServerPipelineFactory, and also > require access to the ChannelGroup so that I can know when a new channel is > being added and when it is removed. > I also sometimes use the channelGroup to send a message to all clients. > In 2.11.1 it was easy to get access to the ChannelGroup through the > NettyConsumer. > However with the 2.12.0 restructure this has been hidden behind the > NettyServerBootstrapFactory interface. > To get around it for now, I looked at implementing my own > NettyServerBootstrapFactory class, but I could not work out how to do that > and also use a custom ServerPipelineFactory. Therefore the solution I came up > with for now is Reflection! > Basically, I am wondering is it possible to modify the > NettyServerBootstrapFactory interface so that the addChannel and > removeChannel methods return the boolean from the channelGroup calls. And > either provide a getter for the channelGroup, or add a writeAllChannels (bulk > write) method interface that does the write method on the channelGroup? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7054) CamelNetty - No way to get ChannelGroup
[ https://issues.apache.org/jira/browse/CAMEL-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7054: --- Fix Version/s: Future > CamelNetty - No way to get ChannelGroup > --- > > Key: CAMEL-7054 > URL: https://issues.apache.org/jira/browse/CAMEL-7054 > Project: Camel > Issue Type: Improvement > Components: camel-netty >Affects Versions: 2.12.0, 2.12.1, 2.12.2 >Reporter: Matthew McMahon >Priority: Trivial > Fix For: Future > > > My use case is that I need to create a custom ServerPipelineFactory, and also > require access to the ChannelGroup so that I can know when a new channel is > being added and when it is removed. > I also sometimes use the channelGroup to send a message to all clients. > In 2.11.1 it was easy to get access to the ChannelGroup through the > NettyConsumer. > However with the 2.12.0 restructure this has been hidden behind the > NettyServerBootstrapFactory interface. > To get around it for now, I looked at implementing my own > NettyServerBootstrapFactory class, but I could not work out how to do that > and also use a custom ServerPipelineFactory. Therefore the solution I came up > with for now is Reflection! > Basically, I am wondering is it possible to modify the > NettyServerBootstrapFactory interface so that the addChannel and > removeChannel methods return the boolean from the channelGroup calls. And > either provide a getter for the channelGroup, or add a writeAllChannels (bulk > write) method interface that does the write method on the channelGroup? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7054) CamelNetty - No way to get ChannelGroup
[ https://issues.apache.org/jira/browse/CAMEL-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623257#comment-14623257 ] Claus Ibsen commented on CAMEL-7054: Yeah sure you are welcome to look at providing a patch. I suggest to look at the api which may have changed a bit and do this for camel-netty4. > CamelNetty - No way to get ChannelGroup > --- > > Key: CAMEL-7054 > URL: https://issues.apache.org/jira/browse/CAMEL-7054 > Project: Camel > Issue Type: Improvement > Components: camel-netty4 >Affects Versions: 2.12.0, 2.12.1, 2.12.2 >Reporter: Matthew McMahon >Priority: Trivial > Fix For: Future > > > My use case is that I need to create a custom ServerPipelineFactory, and also > require access to the ChannelGroup so that I can know when a new channel is > being added and when it is removed. > I also sometimes use the channelGroup to send a message to all clients. > In 2.11.1 it was easy to get access to the ChannelGroup through the > NettyConsumer. > However with the 2.12.0 restructure this has been hidden behind the > NettyServerBootstrapFactory interface. > To get around it for now, I looked at implementing my own > NettyServerBootstrapFactory class, but I could not work out how to do that > and also use a custom ServerPipelineFactory. Therefore the solution I came up > with for now is Reflection! > Basically, I am wondering is it possible to modify the > NettyServerBootstrapFactory interface so that the addChannel and > removeChannel methods return the boolean from the channelGroup calls. And > either provide a getter for the channelGroup, or add a writeAllChannels (bulk > write) method interface that does the write method on the channelGroup? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7054) CamelNetty - No way to get ChannelGroup
[ https://issues.apache.org/jira/browse/CAMEL-7054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7054: --- Component/s: (was: camel-netty) camel-netty4 > CamelNetty - No way to get ChannelGroup > --- > > Key: CAMEL-7054 > URL: https://issues.apache.org/jira/browse/CAMEL-7054 > Project: Camel > Issue Type: Improvement > Components: camel-netty4 >Affects Versions: 2.12.0, 2.12.1, 2.12.2 >Reporter: Matthew McMahon >Priority: Trivial > Fix For: Future > > > My use case is that I need to create a custom ServerPipelineFactory, and also > require access to the ChannelGroup so that I can know when a new channel is > being added and when it is removed. > I also sometimes use the channelGroup to send a message to all clients. > In 2.11.1 it was easy to get access to the ChannelGroup through the > NettyConsumer. > However with the 2.12.0 restructure this has been hidden behind the > NettyServerBootstrapFactory interface. > To get around it for now, I looked at implementing my own > NettyServerBootstrapFactory class, but I could not work out how to do that > and also use a custom ServerPipelineFactory. Therefore the solution I came up > with for now is Reflection! > Basically, I am wondering is it possible to modify the > NettyServerBootstrapFactory interface so that the addChannel and > removeChannel methods return the boolean from the channelGroup calls. And > either provide a getter for the channelGroup, or add a writeAllChannels (bulk > write) method interface that does the write method on the channelGroup? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7040) Support calling OGNL expressions on headers accessed using in.headers[header.name] expression?
[
https://issues.apache.org/jira/browse/CAMEL-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7040.
Resolution: Not A Problem
Assignee: Claus Ibsen
Already possible today. If you header has a key with dots, use single quotes
around it
> Support calling OGNL expressions on headers accessed using
> in.headers[header.name] expression?
> --
>
> Key: CAMEL-7040
> URL: https://issues.apache.org/jira/browse/CAMEL-7040
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 2.12.2
>Reporter: Andrew
>Assignee: Claus Ibsen
>Priority: Minor
> Labels: Simple
>
> After spending a while trying to figure out how to get Camel to call an OGNL
> expression on a bean in the Exchange headers with the Simple Language, I
> discovered that I had gone about it completely the wrong way.
> What I have is a header, "soap.headers.blah", which is an object. I wanted to
> access a property, prop, on that header.
> Initially I tried ${in.headers.soap.headers.blah.prop}, which didn't work.
> I then spent quite a bit of time trying variations on
> ${in.headers[soap.headers.blah].prop}, none of which worked. Now, the
> documentation never said that what I was trying to do would work, so I only
> have myself to blame for that, but I think it would be quite nice if the
> second form *did* work, so that in addition to having the following:
> {{code}}
> header.foo.OGNL
> in.header.foo.OGNL
> in.headers.foo.OGNL
> {{code}}
> I could also do
> {{code}}
> header[foo.bar].OGNL
> in.header[foo.bar].OGNL
> in.headers[foo.bar].OGNL
> {{code}}
> I don't know what this involves - I suspect it's not terribly straightforward
> - but it would be nice to have an option for accessing properties on headers
> whose names include periods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-6997) examples - The online documentation of CDI example is missing.
[ https://issues.apache.org/jira/browse/CAMEL-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6997. Resolution: Fixed Assignee: Claus Ibsen Fix Version/s: 2.16.0 > examples - The online documentation of CDI example is missing. > -- > > Key: CAMEL-6997 > URL: https://issues.apache.org/jira/browse/CAMEL-6997 > Project: Camel > Issue Type: Task > Components: examples >Affects Versions: 2.12.1 >Reporter: Babak Vahdat >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > See: > https://github.com/apache/camel/blob/master/examples/camel-example-cdi/README.txt > According that README.txt we need a documentation for this example @ > http://camel.apache.org/cdi-example.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6913) Add dynamic unmarshalling capability to JiBX data format
[ https://issues.apache.org/jira/browse/CAMEL-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623259#comment-14623259 ] Claus Ibsen commented on CAMEL-6913: Did you ever get started on a patch? > Add dynamic unmarshalling capability to JiBX data format > > > Key: CAMEL-6913 > URL: https://issues.apache.org/jira/browse/CAMEL-6913 > Project: Camel > Issue Type: Improvement > Components: camel-jibx >Affects Versions: 2.12.1 >Reporter: Strelok >Priority: Minor > Fix For: Future > > > Currently a single instance of a JibxDataFormat supports unmarshalling a > single class only as defined by the "unmarshallClass" attribute. If the > application needs to be able to unmarshall to many classes an instance of a > data format has to be created for every class which makes configuration > tedious and verbose. > Should be trivial to make the data format support dynamically choosing which > unmarshall class to use via a header (CamelJibxUnmarshallClass for example). > Creating this issue as a placeholder. I will try to submit a patch soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6913) Add dynamic unmarshalling capability to JiBX data format
[ https://issues.apache.org/jira/browse/CAMEL-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6913: --- Fix Version/s: Future > Add dynamic unmarshalling capability to JiBX data format > > > Key: CAMEL-6913 > URL: https://issues.apache.org/jira/browse/CAMEL-6913 > Project: Camel > Issue Type: Improvement > Components: camel-jibx >Affects Versions: 2.12.1 >Reporter: Strelok >Priority: Minor > Fix For: Future > > > Currently a single instance of a JibxDataFormat supports unmarshalling a > single class only as defined by the "unmarshallClass" attribute. If the > application needs to be able to unmarshall to many classes an instance of a > data format has to be created for every class which makes configuration > tedious and verbose. > Should be trivial to make the data format support dynamically choosing which > unmarshall class to use via a header (CamelJibxUnmarshallClass for example). > Creating this issue as a placeholder. I will try to submit a patch soon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6858) Delayer EIP - Add JMX attribute to know if any messages are delayed
[ https://issues.apache.org/jira/browse/CAMEL-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6858: --- Assignee: (was: Christian Posta) > Delayer EIP - Add JMX attribute to know if any messages are delayed > --- > > Key: CAMEL-6858 > URL: https://issues.apache.org/jira/browse/CAMEL-6858 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.12.1 >Reporter: Christian Posta >Priority: Minor > > continuation of work done here: > https://issues.apache.org/jira/browse/CAMEL-6670 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6858) Delayer EIP - Add JMX attribute to know if any messages are delayed
[ https://issues.apache.org/jira/browse/CAMEL-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6858. Resolution: Fixed Assignee: Claus Ibsen > Delayer EIP - Add JMX attribute to know if any messages are delayed > --- > > Key: CAMEL-6858 > URL: https://issues.apache.org/jira/browse/CAMEL-6858 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.12.1 >Reporter: Christian Posta >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.16.0 > > > continuation of work done here: > https://issues.apache.org/jira/browse/CAMEL-6670 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6858) Delayer EIP - Add JMX attribute to know if any messages are delayed
[ https://issues.apache.org/jira/browse/CAMEL-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6858: --- Fix Version/s: 2.16.0 > Delayer EIP - Add JMX attribute to know if any messages are delayed > --- > > Key: CAMEL-6858 > URL: https://issues.apache.org/jira/browse/CAMEL-6858 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.12.1 >Reporter: Christian Posta >Priority: Minor > Fix For: 2.16.0 > > > continuation of work done here: > https://issues.apache.org/jira/browse/CAMEL-6670 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6840) Allow Throttler EIP to specify SLA per client/correlated-group
[ https://issues.apache.org/jira/browse/CAMEL-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6840: --- Fix Version/s: Future > Allow Throttler EIP to specify SLA per client/correlated-group > -- > > Key: CAMEL-6840 > URL: https://issues.apache.org/jira/browse/CAMEL-6840 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Reporter: Christian Posta > Fix For: Future > > > Basic idea is to allow throttler to have a predicate to determine whether or > not to apply throttling to that exchange. > From this Mailing List discussion: > http://camel.465427.n5.nabble.com/Throttling-by-client-ID-td5741032.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6840) Allow Throttler EIP to specify SLA per client/correlated-group
[ https://issues.apache.org/jira/browse/CAMEL-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6840: --- Priority: Major (was: Minor) > Allow Throttler EIP to specify SLA per client/correlated-group > -- > > Key: CAMEL-6840 > URL: https://issues.apache.org/jira/browse/CAMEL-6840 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Reporter: Christian Posta > Fix For: Future > > > Basic idea is to allow throttler to have a predicate to determine whether or > not to apply throttling to that exchange. > From this Mailing List discussion: > http://camel.465427.n5.nabble.com/Throttling-by-client-ID-td5741032.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6840) Allow Throttler EIP to specify SLA per client/correlated-group
[ https://issues.apache.org/jira/browse/CAMEL-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6840: --- Component/s: eip camel-core > Allow Throttler EIP to specify SLA per client/correlated-group > -- > > Key: CAMEL-6840 > URL: https://issues.apache.org/jira/browse/CAMEL-6840 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Reporter: Christian Posta > Fix For: Future > > > Basic idea is to allow throttler to have a predicate to determine whether or > not to apply throttling to that exchange. > From this Mailing List discussion: > http://camel.465427.n5.nabble.com/Throttling-by-client-ID-td5741032.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6840) Allow Throttler EIP to specify SLA per client/correlated-group
[ https://issues.apache.org/jira/browse/CAMEL-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623262#comment-14623262 ] Claus Ibsen commented on CAMEL-6840: I think we have another ticket about this, to allow throttler to have a correlation group like aggregator, so we can also group them and have different per group. And then a predicate like this to determine to throttle or not. > Allow Throttler EIP to specify SLA per client/correlated-group > -- > > Key: CAMEL-6840 > URL: https://issues.apache.org/jira/browse/CAMEL-6840 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Reporter: Christian Posta > Fix For: Future > > > Basic idea is to allow throttler to have a predicate to determine whether or > not to apply throttling to that exchange. > From this Mailing List discussion: > http://camel.465427.n5.nabble.com/Throttling-by-client-ID-td5741032.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6829) Enhance JettyHttpBinding to control how to convert Camel message into JettyExchage
[ https://issues.apache.org/jira/browse/CAMEL-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623264#comment-14623264 ] Claus Ibsen commented on CAMEL-6829: And how would you do that. You can implemenet / extend the binding and use your custom. > Enhance JettyHttpBinding to control how to convert Camel message into > JettyExchage > -- > > Key: CAMEL-6829 > URL: https://issues.apache.org/jira/browse/CAMEL-6829 > Project: Camel > Issue Type: Improvement > Components: camel-jetty >Affects Versions: 2.12.1 >Reporter: Mateusz Nowakowski >Priority: Minor > > Currently JettyHttpProducer has some limitations which currently can be > solved by introducing yet another options on endpoint or on message level. > For example JettyHttpProducer > produces non-chunked HTTP request only when: > - context type is application/x-java-serialized-object > - or the body is actually a String only -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6826: --- Assignee: (was: James Carman) > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6826) Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing
[ https://issues.apache.org/jira/browse/CAMEL-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6826. Resolution: Not A Problem Its fine and fast now > Use Mock Objects Instead of Live HazelcastInstances to Speed Up Testing > --- > > Key: CAMEL-6826 > URL: https://issues.apache.org/jira/browse/CAMEL-6826 > Project: Camel > Issue Type: Improvement > Components: camel-hazelcast >Reporter: James Carman > > The unit tests for the camel-hazelcast component use real HazelcastInstance > objects, which is very slow. We should use mock objects instead to speed up > testing. Testing the integration can be done with a few, select tests, but > the majority of the logic can be tested with mocks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[
https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623267#comment-14623267
]
Claus Ibsen commented on CAMEL-6768:
The problem is that
public @interface Header {
String value();
}
Is a single value so you can just do @Header("foo") but if you add another
option like
public @interface Header {
String value();
boolean required() default false;
}
Then you must specify the header as @Header(value = "foo") or change the name
of value to name
public @interface Header {
String name();
boolean required() default false;
}
so you can do @Header(name = "foo")
In all cases its a api breaking change, and also its more verbose.
> @Header @Body @Property bean parameter binding - add mandatory option
> -
>
> Key: CAMEL-6768
> URL: https://issues.apache.org/jira/browse/CAMEL-6768
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: Future
>
>
> See
> http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641
> We could have an attribute mandatory = true, which is default true for these
> bean parameter annotations. Then people can set it to false, if a @Header is
> not mandatory (eg do not fail if the header is not present).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6768) @Header @Body @Property bean parameter binding - add mandatory option
[ https://issues.apache.org/jira/browse/CAMEL-6768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6768: --- Fix Version/s: 3.0.0 > @Header @Body @Property bean parameter binding - add mandatory option > - > > Key: CAMEL-6768 > URL: https://issues.apache.org/jira/browse/CAMEL-6768 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.0.0, Future > > > See > http://stackoverflow.com/questions/18874641/add-string-to-camel-exchange-header-from-route?noredirect=1#comment27863978_18874641 > We could have an attribute mandatory = true, which is default true for these > bean parameter annotations. Then people can set it to false, if a @Header is > not mandatory (eg do not fail if the header is not present). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6715) camel-test-blueprint - Only one Camel context gets started on test startup
[ https://issues.apache.org/jira/browse/CAMEL-6715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6715: --- Fix Version/s: 2.16.0 > camel-test-blueprint - Only one Camel context gets started on test startup > -- > > Key: CAMEL-6715 > URL: https://issues.apache.org/jira/browse/CAMEL-6715 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.11.2, 2.12.0 >Reporter: Ievgen Tarasov >Priority: Minor > Fix For: 2.16.0 > > Attachments: JUnit_MultipleContexts.patch > > > In a test made with camel-test-blueprint, and where there is more than one > Camel context per Bundle, only one of them gets started. Actually this > problem was introduced with the fix for CAMEL-6524. Before the fix every > Camel Context would be started after it was created. Now only a context which > is "associated" with the test is getting started. > For camel-test-spring there is a similar problem. Though it looks to me that > in spring multiple contexts didnt work even before CAMEL-6524. > I've attached a patch that introduces a simple junit test for this problem > (for both blueprint and spring). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6715) camel-test-blueprint - Only one Camel context gets started on test startup
[ https://issues.apache.org/jira/browse/CAMEL-6715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6715: --- Priority: Major (was: Minor) > camel-test-blueprint - Only one Camel context gets started on test startup > -- > > Key: CAMEL-6715 > URL: https://issues.apache.org/jira/browse/CAMEL-6715 > Project: Camel > Issue Type: Improvement > Components: camel-test >Affects Versions: 2.11.2, 2.12.0 >Reporter: Ievgen Tarasov > Fix For: 2.16.0 > > Attachments: JUnit_MultipleContexts.patch > > > In a test made with camel-test-blueprint, and where there is more than one > Camel context per Bundle, only one of them gets started. Actually this > problem was introduced with the fix for CAMEL-6524. Before the fix every > Camel Context would be started after it was created. Now only a context which > is "associated" with the test is getting started. > For camel-test-spring there is a similar problem. Though it looks to me that > in spring multiple contexts didnt work even before CAMEL-6524. > I've attached a patch that introduces a simple junit test for this problem > (for both blueprint and spring). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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-tabpanel&focusedCommentId=14623268#comment-14623268 ] Claus Ibsen commented on CAMEL-6707: We are on servlet 3.0 now. We could likely make that mandatory to require 3.0+ and offer async in camel-servlet. > 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 > Fix For: Future > > > 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.3.4#6332)
[jira] [Updated] (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:all-tabpanel ] Claus Ibsen updated CAMEL-6707: --- Fix Version/s: (was: Future) 2.16.0 > 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 > Fix For: 2.16.0 > > > 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.3.4#6332)
[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-tabpanel&focusedCommentId=14623271#comment-14623271 ] Claus Ibsen commented on CAMEL-6707: Anyone wanna work on a patch? > 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 > Fix For: 2.16.0 > > > 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.3.4#6332)
[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-tabpanel&focusedCommentId=14623269#comment-14623269 ] Claus Ibsen commented on CAMEL-6707: Karaf 2.4 is on servlet 3.0 also karaf@root> la | grep -i servlet [ 80] [Active ] [] [ ] [ 30] Servlet 3.0 (1.0) > 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 > Fix For: 2.16.0 > > > 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.3.4#6332)
[jira] [Updated] (CAMEL-6664) Java DSL - Predicates built using ValueBuilder - Map to simple language so we can dump route as text and preserve the predicate
[ https://issues.apache.org/jira/browse/CAMEL-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6664: --- Fix Version/s: (was: Future) 2.16.0 > Java DSL - Predicates built using ValueBuilder - Map to simple language so we > can dump route as text and preserve the predicate > --- > > Key: CAMEL-6664 > URL: https://issues.apache.org/jira/browse/CAMEL-6664 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > See CAMEL-6593 > Lets see if we can turn these ValueBuilder header isNotNull isGreatThan etc > into a simple language predicate/expression. That would allow us to preserve > it when dumping the route as xml model. > This also allows people to reverse engineer java route and adjust them, as > well for tooling to understand the predicates/expressions used in the route. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6660) JMX - Using custom @ManagedResource and extending default components can cause some attributes to be unavailable
[ https://issues.apache.org/jira/browse/CAMEL-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6660: --- Estimated Complexity: Moderate (was: Unknown) > JMX - Using custom @ManagedResource and extending default components can > cause some attributes to be unavailable > > > Key: CAMEL-6660 > URL: https://issues.apache.org/jira/browse/CAMEL-6660 > Project: Camel > Issue Type: Improvement > Components: camel-core, jmx >Reporter: Claus Ibsen > Fix For: Future > > > Related to CAMEL-6586 > Its when you use a custom @ManagedResource such as in a custom component, > then some of the out of the box attributes such as camelId, state, etc may be > shown as Unavailable in JMX consoles. > Its the MBean assembler and JMX in general that needs to find some way of > being able to mixin the custom attributes/operations with the out of the box > ones. So you dont have to copy the out of the box attributes to your custom > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-6664) Java DSL - Predicates built using ValueBuilder - Map to simple language so we can dump route as text and preserve the predicate
[ https://issues.apache.org/jira/browse/CAMEL-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-6664: -- Assignee: Claus Ibsen > Java DSL - Predicates built using ValueBuilder - Map to simple language so we > can dump route as text and preserve the predicate > --- > > Key: CAMEL-6664 > URL: https://issues.apache.org/jira/browse/CAMEL-6664 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.16.0 > > > See CAMEL-6593 > Lets see if we can turn these ValueBuilder header isNotNull isGreatThan etc > into a simple language predicate/expression. That would allow us to preserve > it when dumping the route as xml model. > This also allows people to reverse engineer java route and adjust them, as > well for tooling to understand the predicates/expressions used in the route. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6649) AWS Simple Email Service - add attachment support
[ https://issues.apache.org/jira/browse/CAMEL-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623272#comment-14623272 ] Claus Ibsen commented on CAMEL-6649: Anyone wanna help with this? > AWS Simple Email Service - add attachment support > - > > Key: CAMEL-6649 > URL: https://issues.apache.org/jira/browse/CAMEL-6649 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 2.11.1 >Reporter: Sam Lewis > Fix For: Future > > > The current AWS-SES functionality does not support email attachments. > To send an email with attachments in SES you need to use a RawMessage: > http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-raw.html > I am thinking the easiest way of implementing this feature is send a raw > email if getIn().getBody() is a javax.mail.Message otherwise do the current > processing. > If this seems like a reasonable approach, I would be happy to provide a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6649) AWS Simple Email Service - add attachment support
[ https://issues.apache.org/jira/browse/CAMEL-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6649: --- Fix Version/s: Future > AWS Simple Email Service - add attachment support > - > > Key: CAMEL-6649 > URL: https://issues.apache.org/jira/browse/CAMEL-6649 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 2.11.1 >Reporter: Sam Lewis > Fix For: Future > > > The current AWS-SES functionality does not support email attachments. > To send an email with attachments in SES you need to use a RawMessage: > http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-raw.html > I am thinking the easiest way of implementing this feature is send a raw > email if getIn().getBody() is a javax.mail.Message otherwise do the current > processing. > If this seems like a reasonable approach, I would be happy to provide a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-6649) AWS Simple Email Service - add attachment support
[ https://issues.apache.org/jira/browse/CAMEL-6649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6649: --- Estimated Complexity: Novice (was: Unknown) > AWS Simple Email Service - add attachment support > - > > Key: CAMEL-6649 > URL: https://issues.apache.org/jira/browse/CAMEL-6649 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Affects Versions: 2.11.1 >Reporter: Sam Lewis > Fix For: Future > > > The current AWS-SES functionality does not support email attachments. > To send an email with attachments in SES you need to use a RawMessage: > http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-raw.html > I am thinking the easiest way of implementing this feature is send a raw > email if getIn().getBody() is a javax.mail.Message otherwise do the current > processing. > If this seems like a reasonable approach, I would be happy to provide a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-6647) LevelDb Aggregation Repository: add support for persisting user properties
[
https://issues.apache.org/jira/browse/CAMEL-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-6647.
Resolution: Won't Fix
Relevant user data should be stored in the message, not the exchange.
> LevelDb Aggregation Repository: add support for persisting user properties
> --
>
> Key: CAMEL-6647
> URL: https://issues.apache.org/jira/browse/CAMEL-6647
> Project: Camel
> Issue Type: Improvement
> Components: camel-leveldb
>Reporter: Raúl Kripalani
>Assignee: Raúl Kripalani
>
> Currently, only a limited number of control properties relevant to the
> Aggregator EIP are stored. Extend the {{LevelDbCamelCodec}} to allow storing
> user-specified properties.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6646) Support static method calls on OGNL expressions
[
https://issues.apache.org/jira/browse/CAMEL-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6646:
---
Component/s: (was: camel-ognl)
camel-core
> Support static method calls on OGNL expressions
> ---
>
> Key: CAMEL-6646
> URL: https://issues.apache.org/jira/browse/CAMEL-6646
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Raúl Kripalani
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> In OgnlInvokeProcessor, we currently don't support static method calls as we
> always require a bean instance.
> See this block of code in 2.10.3, starting on OgnlInvokeProcessor:247:
> {code}
> // loop and invoke each method
> Object beanToCall = beanHolder.getBean();
> // there must be a bean to call with, we currently does not support OGNL
> expressions on using purely static methods
> if (beanToCall == null) {
> throw new IllegalArgumentException("Bean instance is null. OGNL bean
> expressions requires bean instances.");
> }
> {code}
> Add support for these cases, especially handy if you use the method()
> expression frequently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-6646) Support static method calls on OGNL expressions
[
https://issues.apache.org/jira/browse/CAMEL-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-6646:
---
Fix Version/s: 2.16.0
> Support static method calls on OGNL expressions
> ---
>
> Key: CAMEL-6646
> URL: https://issues.apache.org/jira/browse/CAMEL-6646
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Raúl Kripalani
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> In OgnlInvokeProcessor, we currently don't support static method calls as we
> always require a bean instance.
> See this block of code in 2.10.3, starting on OgnlInvokeProcessor:247:
> {code}
> // loop and invoke each method
> Object beanToCall = beanHolder.getBean();
> // there must be a bean to call with, we currently does not support OGNL
> expressions on using purely static methods
> if (beanToCall == null) {
> throw new IllegalArgumentException("Bean instance is null. OGNL bean
> expressions requires bean instances.");
> }
> {code}
> Add support for these cases, especially handy if you use the method()
> expression frequently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-6646) Support static method calls on OGNL expressions
[
https://issues.apache.org/jira/browse/CAMEL-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-6646:
--
Assignee: Claus Ibsen (was: Raúl Kripalani)
> Support static method calls on OGNL expressions
> ---
>
> Key: CAMEL-6646
> URL: https://issues.apache.org/jira/browse/CAMEL-6646
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Raúl Kripalani
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> In OgnlInvokeProcessor, we currently don't support static method calls as we
> always require a bean instance.
> See this block of code in 2.10.3, starting on OgnlInvokeProcessor:247:
> {code}
> // loop and invoke each method
> Object beanToCall = beanHolder.getBean();
> // there must be a bean to call with, we currently does not support OGNL
> expressions on using purely static methods
> if (beanToCall == null) {
> throw new IllegalArgumentException("Bean instance is null. OGNL bean
> expressions requires bean instances.");
> }
> {code}
> Add support for these cases, especially handy if you use the method()
> expression frequently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-6646) Support static method calls on OGNL expressions
[
https://issues.apache.org/jira/browse/CAMEL-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623274#comment-14623274
]
Claus Ibsen commented on CAMEL-6646:
This is the bean/simple language. Wonder if this is still a problem today, as
its been enhanced over the time.
> Support static method calls on OGNL expressions
> ---
>
> Key: CAMEL-6646
> URL: https://issues.apache.org/jira/browse/CAMEL-6646
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Raúl Kripalani
>Assignee: Claus Ibsen
> Fix For: 2.16.0
>
>
> In OgnlInvokeProcessor, we currently don't support static method calls as we
> always require a bean instance.
> See this block of code in 2.10.3, starting on OgnlInvokeProcessor:247:
> {code}
> // loop and invoke each method
> Object beanToCall = beanHolder.getBean();
> // there must be a bean to call with, we currently does not support OGNL
> expressions on using purely static methods
> if (beanToCall == null) {
> throw new IllegalArgumentException("Bean instance is null. OGNL bean
> expressions requires bean instances.");
> }
> {code}
> Add support for these cases, especially handy if you use the method()
> expression frequently.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
