[jira] [Updated] (CAMEL-7884) camel-netty4-http does not work for HTTP POST requests
[
https://issues.apache.org/jira/browse/CAMEL-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7884:
---
Affects Version/s: (was: 2.14.1)
> camel-netty4-http does not work for HTTP POST requests
> --
>
> Key: CAMEL-7884
> URL: https://issues.apache.org/jira/browse/CAMEL-7884
> Project: Camel
> Issue Type: Bug
> Components: camel-netty4-http
>Affects Versions: 2.14.0
>Reporter: Yaron A
>
> I tried to add the camel-netty4-http component to a proper working project
> that uses camel-netty-http.
> HTTP GET requests are working properly but POST requests are not working.
> It might be an issue in Netty but I could not find a solution to get it to
> work.
> Here is the exception I see:
> 2014-10-01 09:12:18,012 DEBUG [042ase_1412143933559.data]
> [n.s.ehcache.store.disk.Segment] fault removed 0 from heap
> 2014-10-01 09:12:18,012 DEBUG [042ase_1412143933559.data]
> [n.s.ehcache.store.disk.Segment] fault added 0 on disk
> 2014-10-01 09:12:18,012 TRACE [pool-1-thread-1 ]
> [o.a.c.i.c.DefaultTypeConverter] Converting
> io.netty.util.IllegalReferenceCountException -> java.lang.Throwable with
> value: {}
> io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1187)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1170)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:676)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1461)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> org.apache.camel.component.netty4.http.NettyChannelBufferStreamCache.read(NettyChannelBufferStreamCache.java:69)
> ~[camel-netty4-http-2.14.0.jar:2.14.0]
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> ~[na:1.8.0]
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) ~[na:1.8.0]
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) ~[na:1.8.0]
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> ~[na:1.8.0]
> at java.io.BufferedReader.fill(BufferedReader.java:161) ~[na:1.8.0]
> at java.io.BufferedReader.read1(BufferedReader.java:212) ~[na:1.8.0]
> at java.io.BufferedReader.read(BufferedReader.java:286) ~[na:1.8.0]
> at java.io.Reader.read(Reader.java:140) ~[na:1.8.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:304)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:290)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:351)
> ~[camel-core-2.14.0.jar:2.14.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0]
> at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0]
> at
> org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:1002)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.StaticMethodTypeConverter.convertTo(StaticMethodTypeConverter.java:59)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.doConvertTo(BaseTypeConverterRegistry.java:276)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:165)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:99)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.builder.ExpressionBuilder$41.evaluate(ExpressionBuilder.java:1011)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:36)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.component.bean.MethodInfo$2.evaluateParameterBinding(MethodInfo.java:595)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.component.bean.MethodInfo$2.evaluate(MethodInfo.java:485)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.component.bean.MethodInfo.createMethodInvocation(MethodInfo.java:240)
> ~[camel-core-2.14.0.jar:2.14.0]
>
[jira] [Commented] (CAMEL-7884) camel-netty4-http does not work for HTTP POST requests
[
https://issues.apache.org/jira/browse/CAMEL-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154452#comment-14154452
]
Claus Ibsen commented on CAMEL-7884:
Can you tell more about your HTTP POST. Maybe you can provide the details how
that request "looks like" eg its HTTP headers and body etc. We do have unit
tests that works with HTTP POST so it works in general.
> camel-netty4-http does not work for HTTP POST requests
> --
>
> Key: CAMEL-7884
> URL: https://issues.apache.org/jira/browse/CAMEL-7884
> Project: Camel
> Issue Type: Bug
> Components: camel-netty4-http
>Affects Versions: 2.14.0
>Reporter: Yaron A
>
> I tried to add the camel-netty4-http component to a proper working project
> that uses camel-netty-http.
> HTTP GET requests are working properly but POST requests are not working.
> It might be an issue in Netty but I could not find a solution to get it to
> work.
> Here is the exception I see:
> 2014-10-01 09:12:18,012 DEBUG [042ase_1412143933559.data]
> [n.s.ehcache.store.disk.Segment] fault removed 0 from heap
> 2014-10-01 09:12:18,012 DEBUG [042ase_1412143933559.data]
> [n.s.ehcache.store.disk.Segment] fault added 0 on disk
> 2014-10-01 09:12:18,012 TRACE [pool-1-thread-1 ]
> [o.a.c.i.c.DefaultTypeConverter] Converting
> io.netty.util.IllegalReferenceCountException -> java.lang.Throwable with
> value: {}
> io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1187)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1170)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:676)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1461)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> org.apache.camel.component.netty4.http.NettyChannelBufferStreamCache.read(NettyChannelBufferStreamCache.java:69)
> ~[camel-netty4-http-2.14.0.jar:2.14.0]
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> ~[na:1.8.0]
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) ~[na:1.8.0]
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) ~[na:1.8.0]
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> ~[na:1.8.0]
> at java.io.BufferedReader.fill(BufferedReader.java:161) ~[na:1.8.0]
> at java.io.BufferedReader.read1(BufferedReader.java:212) ~[na:1.8.0]
> at java.io.BufferedReader.read(BufferedReader.java:286) ~[na:1.8.0]
> at java.io.Reader.read(Reader.java:140) ~[na:1.8.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:304)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:290)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:351)
> ~[camel-core-2.14.0.jar:2.14.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0]
> at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0]
> at
> org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:1002)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.StaticMethodTypeConverter.convertTo(StaticMethodTypeConverter.java:59)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.doConvertTo(BaseTypeConverterRegistry.java:276)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:165)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:99)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.builder.ExpressionBuilder$41.evaluate(ExpressionBuilder.java:1011)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:36)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.component.bean.MethodInfo$2.evaluateParameterBinding(MethodInfo.java:595)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.comp
[jira] [Created] (CAMEL-7885) Timer - Restarting a timer endpoint may not trigger at expected time the first time
Claus Ibsen created CAMEL-7885: -- Summary: Timer - Restarting a timer endpoint may not trigger at expected time the first time Key: CAMEL-7885 URL: https://issues.apache.org/jira/browse/CAMEL-7885 Project: Camel Issue Type: Bug Reporter: Claus Ibsen If you stop a timer route, and that route has an inflight exchange causing the stop route to force stop due timeout. Then that timer task is still running in the background. And if you restart the timer route, then it will reuse the old timer instance, which may be still running, and therefore the first trigger time may not happen at the time you would expect. For example from timer:foo?period=2s to trigger every 2s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7885) Timer - Restarting a timer endpoint may not trigger at expected time the first time
[ https://issues.apache.org/jira/browse/CAMEL-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7885: --- Affects Version/s: 2.12.4 2.13.2 2.14.0 > Timer - Restarting a timer endpoint may not trigger at expected time the > first time > --- > > Key: CAMEL-7885 > URL: https://issues.apache.org/jira/browse/CAMEL-7885 > Project: Camel > Issue Type: Bug >Affects Versions: 2.12.4, 2.13.2, 2.14.0 >Reporter: Claus Ibsen > Fix For: 2.12.5, 2.13.3, 2.14.1, 2.15.0 > > > If you stop a timer route, and that route has an inflight exchange causing > the stop route to force stop due timeout. Then that timer task is still > running in the background. > And if you restart the timer route, then it will reuse the old timer > instance, which may be still running, and therefore the first trigger time > may not happen at the time you would expect. > For example from timer:foo?period=2s to trigger every 2s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7885) Timer - Restarting a timer endpoint may not trigger at expected time the first time
[ https://issues.apache.org/jira/browse/CAMEL-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7885: --- Fix Version/s: 2.15.0 2.14.1 2.13.3 2.12.5 > Timer - Restarting a timer endpoint may not trigger at expected time the > first time > --- > > Key: CAMEL-7885 > URL: https://issues.apache.org/jira/browse/CAMEL-7885 > Project: Camel > Issue Type: Bug >Affects Versions: 2.12.4, 2.13.2, 2.14.0 >Reporter: Claus Ibsen > Fix For: 2.12.5, 2.13.3, 2.14.1, 2.15.0 > > > If you stop a timer route, and that route has an inflight exchange causing > the stop route to force stop due timeout. Then that timer task is still > running in the background. > And if you restart the timer route, then it will reuse the old timer > instance, which may be still running, and therefore the first trigger time > may not happen at the time you would expect. > For example from timer:foo?period=2s to trigger every 2s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7885) Timer - Restarting a timer endpoint may not trigger at expected time the first time
[ https://issues.apache.org/jira/browse/CAMEL-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-7885: -- Assignee: Claus Ibsen > Timer - Restarting a timer endpoint may not trigger at expected time the > first time > --- > > Key: CAMEL-7885 > URL: https://issues.apache.org/jira/browse/CAMEL-7885 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.12.4, 2.13.2, 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.12.5, 2.13.3, 2.14.1, 2.15.0 > > > If you stop a timer route, and that route has an inflight exchange causing > the stop route to force stop due timeout. Then that timer task is still > running in the background. > And if you restart the timer route, then it will reuse the old timer > instance, which may be still running, and therefore the first trigger time > may not happen at the time you would expect. > For example from timer:foo?period=2s to trigger every 2s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7885) Timer - Restarting a timer endpoint may not trigger at expected time the first time
[ https://issues.apache.org/jira/browse/CAMEL-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7885: --- Component/s: camel-core > Timer - Restarting a timer endpoint may not trigger at expected time the > first time > --- > > Key: CAMEL-7885 > URL: https://issues.apache.org/jira/browse/CAMEL-7885 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.12.4, 2.13.2, 2.14.0 >Reporter: Claus Ibsen > Fix For: 2.12.5, 2.13.3, 2.14.1, 2.15.0 > > > If you stop a timer route, and that route has an inflight exchange causing > the stop route to force stop due timeout. Then that timer task is still > running in the background. > And if you restart the timer route, then it will reuse the old timer > instance, which may be still running, and therefore the first trigger time > may not happen at the time you would expect. > For example from timer:foo?period=2s to trigger every 2s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7885) Timer - Restarting a timer endpoint may not trigger at expected time the first time
[ https://issues.apache.org/jira/browse/CAMEL-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7885. Resolution: Fixed > Timer - Restarting a timer endpoint may not trigger at expected time the > first time > --- > > Key: CAMEL-7885 > URL: https://issues.apache.org/jira/browse/CAMEL-7885 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.12.4, 2.13.2, 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.12.5, 2.13.3, 2.14.1, 2.15.0 > > > If you stop a timer route, and that route has an inflight exchange causing > the stop route to force stop due timeout. Then that timer task is still > running in the background. > And if you restart the timer route, then it will reuse the old timer > instance, which may be still running, and therefore the first trigger time > may not happen at the time you would expect. > For example from timer:foo?period=2s to trigger every 2s. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7884) camel-netty4-http does not work for HTTP POST requests on routingSlip
[
https://issues.apache.org/jira/browse/CAMEL-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156612#comment-14156612
]
Claus Ibsen commented on CAMEL-7884:
If you are able to zip together a small application or unit test that
reproduces your bug, then you are welcome to attach that to this JIRA so we can
use that to track down the bug.
> camel-netty4-http does not work for HTTP POST requests on routingSlip
> -
>
> Key: CAMEL-7884
> URL: https://issues.apache.org/jira/browse/CAMEL-7884
> Project: Camel
> Issue Type: Bug
> Components: camel-netty4-http
>Affects Versions: 2.14.0
>Reporter: Yaron A
>
> I tried to add the camel-netty4-http component to a proper working project
> that uses camel-netty-http.
> HTTP GET requests are working properly but POST requests are not working.
> It might be an issue in Netty but I could not find a solution to get it to
> work.
> Here is the exception I see:
> 2014-10-01 09:12:18,012 DEBUG [042ase_1412143933559.data]
> [n.s.ehcache.store.disk.Segment] fault removed 0 from heap
> 2014-10-01 09:12:18,012 DEBUG [042ase_1412143933559.data]
> [n.s.ehcache.store.disk.Segment] fault added 0 on disk
> 2014-10-01 09:12:18,012 TRACE [pool-1-thread-1 ]
> [o.a.c.i.c.DefaultTypeConverter] Converting
> io.netty.util.IllegalReferenceCountException -> java.lang.Throwable with
> value: {}
> io.netty.util.IllegalReferenceCountException: refCnt: 0
> at
> io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1187)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1170)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:676)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:1461)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at io.netty.buffer.CompositeByteBuf.readBytes(CompositeByteBuf.java:40)
> ~[netty-buffer-4.0.23.Final.jar:4.0.23.Final]
> at
> org.apache.camel.component.netty4.http.NettyChannelBufferStreamCache.read(NettyChannelBufferStreamCache.java:69)
> ~[camel-netty4-http-2.14.0.jar:2.14.0]
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> ~[na:1.8.0]
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) ~[na:1.8.0]
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) ~[na:1.8.0]
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> ~[na:1.8.0]
> at java.io.BufferedReader.fill(BufferedReader.java:161) ~[na:1.8.0]
> at java.io.BufferedReader.read1(BufferedReader.java:212) ~[na:1.8.0]
> at java.io.BufferedReader.read(BufferedReader.java:286) ~[na:1.8.0]
> at java.io.Reader.read(Reader.java:140) ~[na:1.8.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:304)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:290)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.converter.IOConverter.toString(IOConverter.java:351)
> ~[camel-core-2.14.0.jar:2.14.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0]
> at java.lang.reflect.Method.invoke(Method.java:483) ~[na:1.8.0]
> at
> org.apache.camel.util.ObjectHelper.invokeMethod(ObjectHelper.java:1002)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.StaticMethodTypeConverter.convertTo(StaticMethodTypeConverter.java:59)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.doConvertTo(BaseTypeConverterRegistry.java:276)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.converter.BaseTypeConverterRegistry.mandatoryConvertTo(BaseTypeConverterRegistry.java:165)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.impl.MessageSupport.getMandatoryBody(MessageSupport.java:99)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.builder.ExpressionBuilder$41.evaluate(ExpressionBuilder.java:1011)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.support.ExpressionAdapter.evaluate(ExpressionAdapter.java:36)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.component.bean.MethodInfo$2.evaluateParameterBinding(MethodInfo.java:595)
> ~[camel-core-2.14.0.jar:2.14.0]
> at
> org.apache.camel.co
[jira] [Updated] (CAMEL-7949) JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage
[ https://issues.apache.org/jira/browse/CAMEL-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7949: --- Priority: Minor (was: Critical) > JmsMessageHelper to support automatic conversion from ByteBuffer to > BytesMessage > > > Key: CAMEL-7949 > URL: https://issues.apache.org/jira/browse/CAMEL-7949 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside >Priority: Minor > > JmsMessageHelper to support automatic conversion from ByteBuffer to > BytesMessage. > Looking at the code, byte[] and InputStream conversion to BytesMessage could > utilize camel's built in type conversion functionality and not reimplement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7926) header "CamelFileLastModified" returned as String in Processor
[
https://issues.apache.org/jira/browse/CAMEL-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7926.
Resolution: Invalid
> header "CamelFileLastModified" returned as String in Processor
> --
>
> Key: CAMEL-7926
> URL: https://issues.apache.org/jira/browse/CAMEL-7926
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.8.6
>Reporter: Alexandru Repede
>Priority: Minor
>
> Given a class that implements _Processor_
> When trying to get _Exchange.FILE_LAST_MODIFIED_ as a java.util.Date, the
> result is null. When calling
> {noformat}
> Date lastModification =
> exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
> {noformat}
> _lastModification_ is null.
> Upon debugging, discovered that the header in question is a String. The call
> {noformat}
> exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED)
> {noformat}
> returns a not null String value.
> How is this possible when even _ExpressionBuilder.dateExpression_ does
> {noformat}
> Date date;
> date = exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7926) header "CamelFileLastModified" returned as String in Processor
[
https://issues.apache.org/jira/browse/CAMEL-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14182825#comment-14182825
]
Claus Ibsen commented on CAMEL-7926:
Please use the user forum / mailing list for questions / help with this.
> header "CamelFileLastModified" returned as String in Processor
> --
>
> Key: CAMEL-7926
> URL: https://issues.apache.org/jira/browse/CAMEL-7926
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.8.6
>Reporter: Alexandru Repede
>Priority: Minor
>
> Given a class that implements _Processor_
> When trying to get _Exchange.FILE_LAST_MODIFIED_ as a java.util.Date, the
> result is null. When calling
> {noformat}
> Date lastModification =
> exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
> {noformat}
> _lastModification_ is null.
> Upon debugging, discovered that the header in question is a String. The call
> {noformat}
> exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED)
> {noformat}
> returns a not null String value.
> How is this possible when even _ExpressionBuilder.dateExpression_ does
> {noformat}
> Date date;
> date = exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7939: --- Priority: Major (was: Critical) > Pluggable RedeliveryStrategy for RedeliveryErrorHandler > --- > > Key: CAMEL-7939 > URL: https://issues.apache.org/jira/browse/CAMEL-7939 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside > > Pluggable RedeliveryStrategy for RedeliveryErrorHandler > The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() > in RedeliveryErrorHandler.process() and executorService.schedule()/submit() > in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted > into a RedeliveryStrategy. > The use case for this is to allow custom scheduled retries using JMS. Most if > not all JMS implementations provide a vendor specific way to schedule a > message for delivery at a specified time in the future. Currently we are > using a custom Processor in onException() blocks (with disableRedelivery=true > and handled=true) to manually schedule messages for redelivery using > ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not > play well with Camel's built in Exchange Properties that deal with retry > count, retry delay, etc and we have ended up duplicating camel's build in > properties using our own custom properties. So that the various interceptors > don't strip them.. and not to mention we have ended up duplicating a large > portion of the RedeliveryErrorHandler's logic in our own Processor. > We do not use camel's built in synchronous retry because it blocks the > calling thread and we do no use the async scheduled retry because it is not > safe, Exchange's are not persisted and when the context is shutdown they will > be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's > not always possible to get an exchange accepted by an endpoint before > shutting down - Think HTTP notifications to clients...) > And we do not use our JMS vendors automatic retry mechanism, because it means > we lose control of the retries on a per route basis (all retry options must > be configured and administered on the broker side). And there is no metadata > in the Exchange about the retry count, message history, etc.. as the original > message is redelivered (transaction rollback/unacked etc). > If the actual logic of sending and scheduling retries was abstracted we could > plug in our own strategy to do this based on our JMS vendor (HornetQ). I > imagine that our implementation would be almost identical for ActiveMQ too > (different JMS header). And we would be willing to submit it back to the > Camel Project. > We would also be willing to submit a patch to pull out logic into a > RedeliveryStrategy, just need a little guidance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7939: --- Estimated Complexity: Advanced (was: Moderate) > Pluggable RedeliveryStrategy for RedeliveryErrorHandler > --- > > Key: CAMEL-7939 > URL: https://issues.apache.org/jira/browse/CAMEL-7939 > Project: Camel > Issue Type: New Feature > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside > > Pluggable RedeliveryStrategy for RedeliveryErrorHandler > The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() > in RedeliveryErrorHandler.process() and executorService.schedule()/submit() > in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted > into a RedeliveryStrategy. > The use case for this is to allow custom scheduled retries using JMS. Most if > not all JMS implementations provide a vendor specific way to schedule a > message for delivery at a specified time in the future. Currently we are > using a custom Processor in onException() blocks (with disableRedelivery=true > and handled=true) to manually schedule messages for redelivery using > ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not > play well with Camel's built in Exchange Properties that deal with retry > count, retry delay, etc and we have ended up duplicating camel's build in > properties using our own custom properties. So that the various interceptors > don't strip them.. and not to mention we have ended up duplicating a large > portion of the RedeliveryErrorHandler's logic in our own Processor. > We do not use camel's built in synchronous retry because it blocks the > calling thread and we do no use the async scheduled retry because it is not > safe, Exchange's are not persisted and when the context is shutdown they will > be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's > not always possible to get an exchange accepted by an endpoint before > shutting down - Think HTTP notifications to clients...) > And we do not use our JMS vendors automatic retry mechanism, because it means > we lose control of the retries on a per route basis (all retry options must > be configured and administered on the broker side). And there is no metadata > in the Exchange about the retry count, message history, etc.. as the original > message is redelivered (transaction rollback/unacked etc). > If the actual logic of sending and scheduling retries was abstracted we could > plug in our own strategy to do this based on our JMS vendor (HornetQ). I > imagine that our implementation would be almost identical for ActiveMQ too > (different JMS header). And we would be willing to submit it back to the > Camel Project. > We would also be willing to submit a patch to pull out logic into a > RedeliveryStrategy, just need a little guidance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7939: --- Issue Type: New Feature (was: Improvement) > Pluggable RedeliveryStrategy for RedeliveryErrorHandler > --- > > Key: CAMEL-7939 > URL: https://issues.apache.org/jira/browse/CAMEL-7939 > Project: Camel > Issue Type: New Feature > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside > > Pluggable RedeliveryStrategy for RedeliveryErrorHandler > The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() > in RedeliveryErrorHandler.process() and executorService.schedule()/submit() > in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted > into a RedeliveryStrategy. > The use case for this is to allow custom scheduled retries using JMS. Most if > not all JMS implementations provide a vendor specific way to schedule a > message for delivery at a specified time in the future. Currently we are > using a custom Processor in onException() blocks (with disableRedelivery=true > and handled=true) to manually schedule messages for redelivery using > ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not > play well with Camel's built in Exchange Properties that deal with retry > count, retry delay, etc and we have ended up duplicating camel's build in > properties using our own custom properties. So that the various interceptors > don't strip them.. and not to mention we have ended up duplicating a large > portion of the RedeliveryErrorHandler's logic in our own Processor. > We do not use camel's built in synchronous retry because it blocks the > calling thread and we do no use the async scheduled retry because it is not > safe, Exchange's are not persisted and when the context is shutdown they will > be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's > not always possible to get an exchange accepted by an endpoint before > shutting down - Think HTTP notifications to clients...) > And we do not use our JMS vendors automatic retry mechanism, because it means > we lose control of the retries on a per route basis (all retry options must > be configured and administered on the broker side). And there is no metadata > in the Exchange about the retry count, message history, etc.. as the original > message is redelivered (transaction rollback/unacked etc). > If the actual logic of sending and scheduling retries was abstracted we could > plug in our own strategy to do this based on our JMS vendor (HornetQ). I > imagine that our implementation would be almost identical for ActiveMQ too > (different JMS header). And we would be willing to submit it back to the > Camel Project. > We would also be willing to submit a patch to pull out logic into a > RedeliveryStrategy, just need a little guidance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7958) Java DSL - Should support nested choice in doTry .. doCatch
Claus Ibsen created CAMEL-7958: -- Summary: Java DSL - Should support nested choice in doTry .. doCatch Key: CAMEL-7958 URL: https://issues.apache.org/jira/browse/CAMEL-7958 Project: Camel Issue Type: Improvement Components: camel-core, eip Affects Versions: 2.14.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.1, 2.15.0 See dev http://camel.465427.n5.nabble.com/Why-this-syntax-is-not-accepted-doTry-doCatch-choiceWhen-tp5757614.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7959) Rest DSL - Add support for onException, interceptor and other cross functionality
Claus Ibsen created CAMEL-7959: -- Summary: Rest DSL - Add support for onException, interceptor and other cross functionality Key: CAMEL-7959 URL: https://issues.apache.org/jira/browse/CAMEL-7959 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.1, 2.15.0 Reporter: Claus Ibsen Assignee: Claus Ibsen It seems that onException, interceptor etc. is not in use when using embedded routes with the rest dsl. There has been some reports of this on the user forum. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7958) Java DSL - Should support nested choice in doTry .. doCatch
[ https://issues.apache.org/jira/browse/CAMEL-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7958. Resolution: Fixed Fix Version/s: 2.13.3 > Java DSL - Should support nested choice in doTry .. doCatch > --- > > Key: CAMEL-7958 > URL: https://issues.apache.org/jira/browse/CAMEL-7958 > Project: Camel > Issue Type: Improvement > Components: camel-core, eip >Affects Versions: 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.13.3, 2.14.1, 2.15.0 > > > See dev > http://camel.465427.n5.nabble.com/Why-this-syntax-is-not-accepted-doTry-doCatch-choiceWhen-tp5757614.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7946) Backward compatibility of RoutingSlip/RecipientList statement is violated
[ https://issues.apache.org/jira/browse/CAMEL-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7946. Resolution: Invalid Use mailing list / user forum to get help with your Camel upgrade. > Backward compatibility of RoutingSlip/RecipientList statement is violated > - > > Key: CAMEL-7946 > URL: https://issues.apache.org/jira/browse/CAMEL-7946 > Project: Camel > Issue Type: Bug >Affects Versions: 2.13.2 >Reporter: Tomas Hanus > Labels: core > > Currently we fixed issue in production of route that uses routingSlip > statement for dynamic resolution of endpoint. This route is synchronous when > next endpoint expects some result from previous endpoint that was resolved by > routingSlip. Problem is, and we don't know how long (camel version), that > without explicit statement which defines ExchangePattern as *InOut* before > using routingSlip unexpected behaviour occurs. It looks like *InOnly* by > default. > *wrong approach*: > .recipientList(method(MyRoute.class, "getUri")).id(ENDPOINT_ID_EXT); > *correct behaviour*: > // for request/reply > .setExchangePattern(ExchangePattern.InOut) > .recipientList(method(MyRoute.class, "getUri")).id(ENDPOINT_ID_EXT); > Because this change is *not backwards compatible* and has a very unexpected > behavior and this issue is difficult to identify. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7937) camel-example-cdi fails on wildfly
[
https://issues.apache.org/jira/browse/CAMEL-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7937:
---
Priority: Minor (was: Major)
> camel-example-cdi fails on wildfly
> --
>
> Key: CAMEL-7937
> URL: https://issues.apache.org/jira/browse/CAMEL-7937
> Project: Camel
> Issue Type: Bug
> Components: camel-cdi, examples
>Affects Versions: 2.14.0
>Reporter: Thomas Diesler
>Priority: Minor
>
> [.. camel-example-cdi]$ mvn clean install -Parquillian-jbossas-managed
> {code}
> Caused by: java.lang.IllegalArgumentException: Packaging type jdocbook is not
> supported.
> at
> org.jboss.shrinkwrap.resolver.api.maven.PackagingType.fromPackagingType(PackagingType.java:65)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependency(MavenConverter.java:149)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependencies(MavenConverter.java:163)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.(PomEquippedResolveStageBaseImpl.java:68)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageImpl.(PomEquippedResolveStageImpl.java:38)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:55)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:30)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:77)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:99)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemBaseImpl.loadPomFromFile(MavenResolverSystemBaseImpl.java:157)
> at
> org.apache.camel.example.cdi.ArchiveUtil.createWarArchive(ArchiveUtil.java:61)
> at
> org.apache.camel.example.cdi.one.DeploymentFactory.createArchive(DeploymentFactory.java:48)
> {code}
> {code}
> Tests in error:
> IntegrationTest.org.apache.camel.example.cdi.one.IntegrationTest » Runtime
> Cou...
>
> SeparateRouteBuilderIntegrationTest.org.apache.camel.example.cdi.two.SeparateRouteBuilderIntegrationTest
> » Runtime
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7937) camel-example-cdi fails on wildfly
[
https://issues.apache.org/jira/browse/CAMEL-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7937:
---
Component/s: examples
camel-cdi
> camel-example-cdi fails on wildfly
> --
>
> Key: CAMEL-7937
> URL: https://issues.apache.org/jira/browse/CAMEL-7937
> Project: Camel
> Issue Type: Bug
> Components: camel-cdi, examples
>Affects Versions: 2.14.0
>Reporter: Thomas Diesler
>
> [.. camel-example-cdi]$ mvn clean install -Parquillian-jbossas-managed
> {code}
> Caused by: java.lang.IllegalArgumentException: Packaging type jdocbook is not
> supported.
> at
> org.jboss.shrinkwrap.resolver.api.maven.PackagingType.fromPackagingType(PackagingType.java:65)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependency(MavenConverter.java:149)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependencies(MavenConverter.java:163)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.(PomEquippedResolveStageBaseImpl.java:68)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageImpl.(PomEquippedResolveStageImpl.java:38)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:55)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:30)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:77)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:99)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemBaseImpl.loadPomFromFile(MavenResolverSystemBaseImpl.java:157)
> at
> org.apache.camel.example.cdi.ArchiveUtil.createWarArchive(ArchiveUtil.java:61)
> at
> org.apache.camel.example.cdi.one.DeploymentFactory.createArchive(DeploymentFactory.java:48)
> {code}
> {code}
> Tests in error:
> IntegrationTest.org.apache.camel.example.cdi.one.IntegrationTest » Runtime
> Cou...
>
> SeparateRouteBuilderIntegrationTest.org.apache.camel.example.cdi.two.SeparateRouteBuilderIntegrationTest
> » Runtime
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7937) camel-example-cdi fails on wildfly
[
https://issues.apache.org/jira/browse/CAMEL-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184071#comment-14184071
]
Claus Ibsen commented on CAMEL-7937:
Have you tried without arquillian and just deploy the example in an existing
running wildfly server?
Also we have no clue what that jdocbook error means? I suspect its not a Camel
issue?
> camel-example-cdi fails on wildfly
> --
>
> Key: CAMEL-7937
> URL: https://issues.apache.org/jira/browse/CAMEL-7937
> Project: Camel
> Issue Type: Bug
> Components: camel-cdi, examples
>Affects Versions: 2.14.0
>Reporter: Thomas Diesler
>Priority: Minor
>
> [.. camel-example-cdi]$ mvn clean install -Parquillian-jbossas-managed
> {code}
> Caused by: java.lang.IllegalArgumentException: Packaging type jdocbook is not
> supported.
> at
> org.jboss.shrinkwrap.resolver.api.maven.PackagingType.fromPackagingType(PackagingType.java:65)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependency(MavenConverter.java:149)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependencies(MavenConverter.java:163)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.(PomEquippedResolveStageBaseImpl.java:68)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageImpl.(PomEquippedResolveStageImpl.java:38)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:55)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:30)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:77)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:99)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemBaseImpl.loadPomFromFile(MavenResolverSystemBaseImpl.java:157)
> at
> org.apache.camel.example.cdi.ArchiveUtil.createWarArchive(ArchiveUtil.java:61)
> at
> org.apache.camel.example.cdi.one.DeploymentFactory.createArchive(DeploymentFactory.java:48)
> {code}
> {code}
> Tests in error:
> IntegrationTest.org.apache.camel.example.cdi.one.IntegrationTest » Runtime
> Cou...
>
> SeparateRouteBuilderIntegrationTest.org.apache.camel.example.cdi.two.SeparateRouteBuilderIntegrationTest
> » Runtime
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7875) Easier write access to Camel context registry
[
https://issues.apache.org/jira/browse/CAMEL-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184074#comment-14184074
]
Claus Ibsen commented on CAMEL-7875:
We have to be careful about this. As Camel does not hosts its own bean registry
but integrates with spring / jndi / cdi / osgi etc. And those have various
features to pre/post process the beans and whatnot.
A Camel registry will thus not offer that functionality, and make it
inconsistent behavior when a bean is found from Camel vs the others.
Also if a bean by type / name is in both which one to choose, and return? (eg
how to handle duplicates) etc.
If the use-case is to make it easier to register beans manually to override
existing beans for unit testing, then its better to improve camel-test. And
leave current as-is.
> Easier write access to Camel context registry
> -
>
> Key: CAMEL-7875
> URL: https://issues.apache.org/jira/browse/CAMEL-7875
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Jyrki Ruuskanen
>Assignee: Willem Jiang
>Priority: Minor
>
> I haven't found a nice way to add beans to Camel context registry through
> Camel context reference in plain Java. Some beans are only needed by a
> certain endpoint and it would make sense to set the bean up with the endpoint
> in routebuilder configure method.
> If we added a reference to self in SimpleRegistry we could setup the Camel
> context by DefaultCamelContext(new SimpleRegistry()) or
> OsgiDefaultCamelContext(bundleContext, new SimpleRegistry()) and easily
> access the registry from the routebuilder with SimpleRegistry registry =
> (SimpleRegistry) getContext().lookupByName(SimpleRegistry.NAME);.
> Then we can set up beans in routebuilder configure and simply add them with
> registry.put. And the same routebuilder could be used in plain Java, in OSGi
> or elsewhere.
> All that is needed is this change in SimpleRegistry:
> {code}
> public static final String NAME;
> static {
>NAME = java.util.UUID.randomUUID().tostring();
> }
> public SimpleRegistry() {
>put.(NAME, this);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7925:
---
Summary: groovy and osgi - Could not initialize class
script1413536396719697720774 (was: Could not initialize class
script1413536396719697720774)
> groovy and osgi - Could not initialize class script1413536396719697720774
> -
>
> Key: CAMEL-7925
> URL: https://issues.apache.org/jira/browse/CAMEL-7925
> Project: Camel
> Issue Type: Bug
> Components: camel-groovy, el-groovy
> Environment: Apache Karaf 2.2.x
>Reporter: Charles Moulliard
>
> When a camel route is deployed on apache Karaf using a groovy expression to
> be evaluated we get this error
> https://gist.github.com/cmoulliard/7294122c47e9c18df399
> Route
> {code}
> from("direct:launch").routeId("request-token")
>
> .onException(HttpOperationFailedException.class)
> .handled(true)
> .log("An error occurred")
> .to("direct:interface-status")
> .end()
>
> .setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
> .setHeader(Exchange.HTTP_QUERY, constant("User=" + UserName +
> "&" + "Pass=" + Password))
> .setHeader(Exchange.HTTP_METHOD, constant("GET"))
>
> .to("https4://token-service")
> .convertBodyTo(String.class)
> .setHeader("token").groovy("body.replaceAll('\"','')")
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> script1413536396719697720774
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.7.0_51]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
> at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
> at
> org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14184076#comment-14184076
]
Claus Ibsen commented on CAMEL-7925:
What version of Camel do you use? Also karaf 2.2.x is old. Use a newer release.
> groovy and osgi - Could not initialize class script1413536396719697720774
> -
>
> Key: CAMEL-7925
> URL: https://issues.apache.org/jira/browse/CAMEL-7925
> Project: Camel
> Issue Type: Bug
> Components: camel-groovy, el-groovy
> Environment: Apache Karaf 2.2.x
>Reporter: Charles Moulliard
>
> When a camel route is deployed on apache Karaf using a groovy expression to
> be evaluated we get this error
> https://gist.github.com/cmoulliard/7294122c47e9c18df399
> Route
> {code}
> from("direct:launch").routeId("request-token")
>
> .onException(HttpOperationFailedException.class)
> .handled(true)
> .log("An error occurred")
> .to("direct:interface-status")
> .end()
>
> .setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
> .setHeader(Exchange.HTTP_QUERY, constant("User=" + UserName +
> "&" + "Pass=" + Password))
> .setHeader(Exchange.HTTP_METHOD, constant("GET"))
>
> .to("https4://token-service")
> .convertBodyTo(String.class)
> .setHeader("token").groovy("body.replaceAll('\"','')")
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> script1413536396719697720774
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.7.0_51]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
> at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
> at
> org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7925:
---
Component/s: (was: el-groovy)
> groovy and osgi - Could not initialize class script1413536396719697720774
> -
>
> Key: CAMEL-7925
> URL: https://issues.apache.org/jira/browse/CAMEL-7925
> Project: Camel
> Issue Type: Bug
> Components: camel-groovy
> Environment: Apache Karaf 2.2.x
>Reporter: Charles Moulliard
>Priority: Minor
>
> When a camel route is deployed on apache Karaf using a groovy expression to
> be evaluated we get this error
> https://gist.github.com/cmoulliard/7294122c47e9c18df399
> Route
> {code}
> from("direct:launch").routeId("request-token")
>
> .onException(HttpOperationFailedException.class)
> .handled(true)
> .log("An error occurred")
> .to("direct:interface-status")
> .end()
>
> .setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
> .setHeader(Exchange.HTTP_QUERY, constant("User=" + UserName +
> "&" + "Pass=" + Password))
> .setHeader(Exchange.HTTP_METHOD, constant("GET"))
>
> .to("https4://token-service")
> .convertBodyTo(String.class)
> .setHeader("token").groovy("body.replaceAll('\"','')")
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> script1413536396719697720774
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.7.0_51]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
> at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
> at
> org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7925) groovy and osgi - Could not initialize class script1413536396719697720774
[
https://issues.apache.org/jira/browse/CAMEL-7925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7925:
---
Priority: Minor (was: Major)
> groovy and osgi - Could not initialize class script1413536396719697720774
> -
>
> Key: CAMEL-7925
> URL: https://issues.apache.org/jira/browse/CAMEL-7925
> Project: Camel
> Issue Type: Bug
> Components: camel-groovy
> Environment: Apache Karaf 2.2.x
>Reporter: Charles Moulliard
>Priority: Minor
>
> When a camel route is deployed on apache Karaf using a groovy expression to
> be evaluated we get this error
> https://gist.github.com/cmoulliard/7294122c47e9c18df399
> Route
> {code}
> from("direct:launch").routeId("request-token")
>
> .onException(HttpOperationFailedException.class)
> .handled(true)
> .log("An error occurred")
> .to("direct:interface-status")
> .end()
>
> .setHeader(Exchange.HTTP_URI, constant(wayneUriGetSession))
> .setHeader(Exchange.HTTP_QUERY, constant("User=" + UserName +
> "&" + "Pass=" + Password))
> .setHeader(Exchange.HTTP_METHOD, constant("GET"))
>
> .to("https4://token-service")
> .convertBodyTo(String.class)
> .setHeader("token").groovy("body.replaceAll('\"','')")
> {code}
> {code}
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class
> script1413536396719697720774
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.7.0_51]
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)[:1.7.0_51]
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)[:1.7.0_51]
> at
> java.lang.reflect.Constructor.newInstance(Constructor.java:526)[:1.7.0_51]
> at java.lang.Class.newInstance(Class.java:374)[:1.7.0_51]
> at
> org.apache.camel.language.groovy.GroovyExpression.instantiateScript(GroovyExpression.java:71)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7965) EndpointCache - Should keep endpoints from routes in the cache
Claus Ibsen created CAMEL-7965: -- Summary: EndpointCache - Should keep endpoints from routes in the cache Key: CAMEL-7965 URL: https://issues.apache.org/jira/browse/CAMEL-7965 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Claus Ibsen Priority: Minor Fix For: Future See http://camel.465427.n5.nabble.com/camelContext-hasEndpoint-returns-null-when-endpoint-apparently-exists-tp5757907.html The endpoint cache is a LRU based. But endpoints created from the routes may not be looked up in the cache for a while, and could potential be evicted from the cache. We should keep those endpoints from the routes in the cache at all times. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7928) Camel-mustache - update to 0.8.17 version of mustache-java
[ https://issues.apache.org/jira/browse/CAMEL-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7928: --- Fix Version/s: 2.15.0 > Camel-mustache - update to 0.8.17 version of mustache-java > -- > > Key: CAMEL-7928 > URL: https://issues.apache.org/jira/browse/CAMEL-7928 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Priority: Minor > Labels: mustache > Fix For: 2.15.0 > > > Currently we use mustache-java version 0.8.16, but it's available version > 0.8.17 since September. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7928) Camel-mustache - update to 0.8.17 version of mustache-java
[ https://issues.apache.org/jira/browse/CAMEL-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7928: --- Affects Version/s: (was: 2.15.0) > Camel-mustache - update to 0.8.17 version of mustache-java > -- > > Key: CAMEL-7928 > URL: https://issues.apache.org/jira/browse/CAMEL-7928 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Priority: Minor > Labels: mustache > > Currently we use mustache-java version 0.8.16, but it's available version > 0.8.17 since September. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7928) Camel-mustache - update to 0.8.17 version of mustache-java
[ https://issues.apache.org/jira/browse/CAMEL-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7928. Resolution: Fixed Assignee: Claus Ibsen > Camel-mustache - update to 0.8.17 version of mustache-java > -- > > Key: CAMEL-7928 > URL: https://issues.apache.org/jira/browse/CAMEL-7928 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Assignee: Claus Ibsen >Priority: Minor > Labels: mustache > Fix For: 2.15.0 > > > Currently we use mustache-java version 0.8.16, but it's available version > 0.8.17 since September. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7981) JMX - Routes with transacted does not enlist processor mbeans
Claus Ibsen created CAMEL-7981: -- Summary: JMX - Routes with transacted does not enlist processor mbeans Key: CAMEL-7981 URL: https://issues.apache.org/jira/browse/CAMEL-7981 Project: Camel Issue Type: Bug Components: camel-core, jmx Affects Versions: 2.14.0, 2.13.2 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.1, 2.15.0, 2.13.4 See nabble http://camel.465427.n5.nabble.com/Not-all-processors-are-listed-in-JMX-preventing-detailed-route-statistics-profiling-tp5757634p5758257.html Routes with < transacted > does not enlist mbeans under processor, but you have mbeans in routes / consumers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7981) JMX - Routes with transacted does not enlist processor mbeans
[ https://issues.apache.org/jira/browse/CAMEL-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7981. Resolution: Fixed > JMX - Routes with transacted does not enlist processor mbeans > - > > Key: CAMEL-7981 > URL: https://issues.apache.org/jira/browse/CAMEL-7981 > Project: Camel > Issue Type: Bug > Components: camel-core, jmx >Affects Versions: 2.13.2, 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.14.1, 2.15.0, 2.13.4 > > > See nabble > http://camel.465427.n5.nabble.com/Not-all-processors-are-listed-in-JMX-preventing-detailed-route-statistics-profiling-tp5757634p5758257.html > Routes with < transacted > does not enlist mbeans under processor, but you > have mbeans in routes / consumers etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7777) GitHub component
[ https://issues.apache.org/jira/browse/CAMEL-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188130#comment-14188130 ] Claus Ibsen commented on CAMEL-: I would also like to see a generic camel-git component that works with any git repository, (not only github) - for that there is jgit library http://www.eclipse.org/jgit/ We use it in fabric8 for git, so its doable. > GitHub component > > > Key: CAMEL- > URL: https://issues.apache.org/jira/browse/CAMEL- > Project: Camel > Issue Type: New Feature >Reporter: Brett E. Meyer >Assignee: Willem Jiang > Fix For: 2.15.0 > > > For Overlord (http://projectoverlord.io), we need to consume "events" from > GitHub, as well as produce "actions". We're moving towards using Camel as a > backbone for various capabilities, and as such are writing the endpoint > functionality as new Camel components. I'd love to see this incorporated as > another mainline Camel component. > Work in progress: > https://github.com/brmeyer/camel-github > Consumer ideas: > github://pullRequest (new pull requests) > github://pullRequestComment (new pull request comments) > github://commit/[branch] (new commits) > github://tag (new tags) > Producer ideas: > github://pullRequestComment/[pr #] > Obviously, that's only a small portion of the capabilities. The GitHub API > is extensive and opens a large variety of possibilities. > It uses the org.eclipse.egit.github.core SDK > (https://github.com/eclipse/egit-github/tree/master/org.eclipse.egit.github.core), > which is a part of Mylyn and licensed under the EPL. So, there shouldn't be > any reason why this would need to be restricted to Camel Extras. > Similar to what I did for camel-twitter, the Exchange payloads would be the > SDK-provided objects themselves (PullRequest, CommitComment, RepositoryTag, > RepositoryCommit, etc.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7982) camel-git - A generic git component
Claus Ibsen created CAMEL-7982: -- Summary: camel-git - A generic git component Key: CAMEL-7982 URL: https://issues.apache.org/jira/browse/CAMEL-7982 Project: Camel Issue Type: New Feature Reporter: Claus Ibsen I would also like to see a generic camel-git component that works with any git repository, (not only github) - for that there is jgit library http://www.eclipse.org/jgit/ We use it in fabric8 for git, so its doable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7984) camel-sjms - Add support for jmsKeyFormatStrategy
Claus Ibsen created CAMEL-7984: -- Summary: camel-sjms - Add support for jmsKeyFormatStrategy Key: CAMEL-7984 URL: https://issues.apache.org/jira/browse/CAMEL-7984 Project: Camel Issue Type: Improvement Components: camel-sjms Affects Versions: 2.14.0 Reporter: Claus Ibsen Priority: Minor See CAMEL-7975 which hardcoded to use the default strategy. But we should allow end users to configure and use their own, and also use the passthrough. Eg see the jmsKeyFormatStrategy option at http://camel.apache.org/jms and implement it at camel-sjms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7975) SJMS Endpoint does not reverse header encoding
[
https://issues.apache.org/jira/browse/CAMEL-7975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7975:
---
Issue Type: Improvement (was: Bug)
> SJMS Endpoint does not reverse header encoding
> --
>
> Key: CAMEL-7975
> URL: https://issues.apache.org/jira/browse/CAMEL-7975
> Project: Camel
> Issue Type: Improvement
> Components: camel-sjms
>Affects Versions: 2.14.0
>Reporter: Aaron Whiteside
>Assignee: Willem Jiang
>Priority: Minor
> Fix For: 2.14.1, 2.15.0, 2.13.4
>
> Attachments: unnamed3.patch
>
>
> SJMS Endpoint does not reverse header encoding, when it replaces . with
> \_DOT\_ and - with \_HYPHEN\_ it does not replace them with the original
> values.
> So this breaks compatibility with the camel-jms component.
> Quote taken from: http://camel.apache.org/jms.html
> {quote}
> The current header name strategy for accepting header names in Camel is as
> follows:
> Dots are replaced by \_DOT\_ and the replacement is reversed when Camel
> consume the message
> Hyphen is replaced by \_HYPHEN\_ and the replacement is reversed when Camel
> consumes the message
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7973) CircuitBreakerLoadBalancer fails on async processors
[ https://issues.apache.org/jira/browse/CAMEL-7973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189740#comment-14189740 ] Claus Ibsen commented on CAMEL-7973: Willem the patch is partly correct, eg the stuff about the exception etc. But calling the processor should be the async with the callback, eg the last part of the patch is not correct. That may need a bit more logic to implement correctly, as you may need to add logic in the callback to do after work in the circuit breaker. I have not yet taken a closer look, but just beware more work is likely needed to fix this properly. > CircuitBreakerLoadBalancer fails on async processors > > > Key: CAMEL-7973 > URL: https://issues.apache.org/jira/browse/CAMEL-7973 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Matteo Pavesi >Assignee: Willem Jiang >Priority: Minor > Attachments: > 0001-CAMEL-7973-added-failing-test-for-circuit-breaker-wi.patch, > 0002-CAMEL-7973-fix-circuit-breaker-with-async-processors.patch > > > The CircuitBreakerLoadBalancer works fine on direct synchronous processor, > but it seems to not behave as expected in case of async processor. > To reproduce the error, it's enough to add a .threads(1) before the mock > processor in the CircuitBreakerLoadBalancerTest routeBuilder configuration. > This misbehaviour seems to be related to the use of the > AsyncProcessorConverterHelper to force any processor to behave like > asynchronous. > I'm going to propose a patch with the failing test and a proposal of solution. > EDIT: > the patch contains the fix also to other unexpected behaviour of the > CircuitBreaker. > The second problem addressed is that, after the opening of the circuit, the > RejectedExecutionException raised by the circuit breaker is set in the > Exchange, but it doesn't return. This cause the processor will receive the > Exchange even if the circuit is open. In this case also, if the > CircuitBreaker is instructed to react only to specific Exception, it will > close the circuit after the following request, because the raised exception > would be a RejectedExecutionException instead of the one specified in the > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
Claus Ibsen created CAMEL-7985:
--
Summary: camel-test-blueprint - Upgrading to newer felix fails
with NPE in fileinstall
Key: CAMEL-7985
URL: https://issues.apache.org/jira/browse/CAMEL-7985
Project: Camel
Issue Type: Improvement
Components: camel-blueprint, camel-test
Affects Versions: 2.14.0
Reporter: Claus Ibsen
Fix For: 2.15.0
We get a bunch of these errors during testing with osgi blueprint
{code}
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
In main loop, we have serious trouble: java.lang.NullPointerException
java.lang.NullPointerException
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
{code}
Run tests here
{code}
camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
{code}
And upgrade Felix in parent/pom.xml
{code}
-1.4.0
-3.2.6
-3.2.2
+1.8.0
+3.4.2
+3.4.2
{code}
And you get these NPEs.
Maybe something needs to be fixed in camel-test-blueprint with that pojosr
library, so bundle 0 is that system bundle, as the NPE is at:
https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189916#comment-14189916
]
Claus Ibsen commented on CAMEL-7985:
The same NPE bugs is when you run mvn clean install in camel-test-blueprint.
> camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
> -
>
> Key: CAMEL-7985
> URL: https://issues.apache.org/jira/browse/CAMEL-7985
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-test
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
> Fix For: 2.15.0
>
>
> We get a bunch of these errors during testing with osgi blueprint
> {code}
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> {code}
> Run tests here
> {code}
> camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
> {code}
> And upgrade Felix in parent/pom.xml
> {code}
> -1.4.0
> -3.2.6
> -3.2.2
> +1.8.0
> +3.4.2
> +3.4.2
> {code}
> And you get these NPEs.
> Maybe something needs to be fixed in camel-test-blueprint with that pojosr
> library, so bundle 0 is that system bundle, as the NPE is at:
> https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189920#comment-14189920
]
Claus Ibsen commented on CAMEL-7985:
The issue is that pojosr inserts itself as bundle 0, so osgi becomes bundle 1.
And felix assume bundle 0 is osgi
> camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
> -
>
> Key: CAMEL-7985
> URL: https://issues.apache.org/jira/browse/CAMEL-7985
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-test
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
> Fix For: 2.15.0
>
>
> We get a bunch of these errors during testing with osgi blueprint
> {code}
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> {code}
> Run tests here
> {code}
> camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
> {code}
> And upgrade Felix in parent/pom.xml
> {code}
> -1.4.0
> -3.2.6
> -3.2.2
> +1.8.0
> +3.4.2
> +3.4.2
> {code}
> And you get these NPEs.
> Maybe something needs to be fixed in camel-test-blueprint with that pojosr
> library, so bundle 0 is that system bundle, as the NPE is at:
> https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189927#comment-14189927
]
Claus Ibsen commented on CAMEL-7985:
Logged ticket with the bug at pojosr
https://code.google.com/p/pojosr/issues/detail?id=13&thanks=13&ts=1414666384
> camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
> -
>
> Key: CAMEL-7985
> URL: https://issues.apache.org/jira/browse/CAMEL-7985
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-test
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
> Fix For: 2.15.0
>
> Attachments: Screen Shot 2014-10-30 at 11.44.58 AM.png
>
>
> We get a bunch of these errors during testing with osgi blueprint
> {code}
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> {code}
> Run tests here
> {code}
> camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
> {code}
> And upgrade Felix in parent/pom.xml
> {code}
> -1.4.0
> -3.2.6
> -3.2.2
> +1.8.0
> +3.4.2
> +3.4.2
> {code}
> And you get these NPEs.
> Maybe something needs to be fixed in camel-test-blueprint with that pojosr
> library, so bundle 0 is that system bundle, as the NPE is at:
> https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7985:
---
Attachment: Screen Shot 2014-10-30 at 11.44.58 AM.png
> camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
> -
>
> Key: CAMEL-7985
> URL: https://issues.apache.org/jira/browse/CAMEL-7985
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-test
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
> Fix For: 2.15.0
>
> Attachments: Screen Shot 2014-10-30 at 11.44.58 AM.png
>
>
> We get a bunch of these errors during testing with osgi blueprint
> {code}
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> {code}
> Run tests here
> {code}
> camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
> {code}
> And upgrade Felix in parent/pom.xml
> {code}
> -1.4.0
> -3.2.6
> -3.2.2
> +1.8.0
> +3.4.2
> +3.4.2
> {code}
> And you get these NPEs.
> Maybe something needs to be fixed in camel-test-blueprint with that pojosr
> library, so bundle 0 is that system bundle, as the NPE is at:
> https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189946#comment-14189946
]
Claus Ibsen commented on CAMEL-7985:
This requires a fix in pojosr or in felix to handle that bundle 0 is not
osgi-core
> camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
> -
>
> Key: CAMEL-7985
> URL: https://issues.apache.org/jira/browse/CAMEL-7985
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-test
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
> Fix For: 2.15.0
>
> Attachments: Screen Shot 2014-10-30 at 11.44.58 AM.png
>
>
> We get a bunch of these errors during testing with osgi blueprint
> {code}
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> {code}
> Run tests here
> {code}
> camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
> {code}
> And upgrade Felix in parent/pom.xml
> {code}
> -1.4.0
> -3.2.6
> -3.2.2
> +1.8.0
> +3.4.2
> +3.4.2
> {code}
> And you get these NPEs.
> Maybe something needs to be fixed in camel-test-blueprint with that pojosr
> library, so bundle 0 is that system bundle, as the NPE is at:
> https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7987) Distro -javadoc JARs has malfuncted .css stylesheet files
Claus Ibsen created CAMEL-7987: -- Summary: Distro -javadoc JARs has malfuncted .css stylesheet files Key: CAMEL-7987 URL: https://issues.apache.org/jira/browse/CAMEL-7987 Project: Camel Issue Type: Task Components: build system Affects Versions: 2.14.0 Reporter: Claus Ibsen For example camel-core -javadoc JAR has a stylesheet.css file embedded that is a bit wrong as the Apache header in the top seems to have cut off some of the css file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7987) Distro -javadoc JARs has malfuncted .css stylesheet files
[ https://issues.apache.org/jira/browse/CAMEL-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191886#comment-14191886 ] Claus Ibsen commented on CAMEL-7987: See issue reported here https://github.com/hawtio/hawtio/issues/1637 > Distro -javadoc JARs has malfuncted .css stylesheet files > - > > Key: CAMEL-7987 > URL: https://issues.apache.org/jira/browse/CAMEL-7987 > Project: Camel > Issue Type: Task > Components: build system >Affects Versions: 2.14.0 >Reporter: Claus Ibsen > > For example camel-core -javadoc JAR has a stylesheet.css file embedded that > is a bit wrong as the Apache header in the top seems to have cut off some of > the css file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7988) file consumer - Should call abort in case read lock cannot be acquired if exception was thrown
Claus Ibsen created CAMEL-7988: -- Summary: file consumer - Should call abort in case read lock cannot be acquired if exception was thrown Key: CAMEL-7988 URL: https://issues.apache.org/jira/browse/CAMEL-7988 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0, 2.13.3 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.1, 2.15.0, 2.13.4 See nabble http://camel.465427.n5.nabble.com/Possible-issue-with-FileLockExclusiveReadLockStrategy-leaves-orphaned-camelLock-file-tp5758142.html This could cause a .camelLock orphaned file to be there causing the file to not be eligible for consuming on next poll. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7989) FileIdempotentRepository should create the file store on startup
Claus Ibsen created CAMEL-7989: -- Summary: FileIdempotentRepository should create the file store on startup Key: CAMEL-7989 URL: https://issues.apache.org/jira/browse/CAMEL-7989 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.0, 2.13.3 Reporter: Claus Ibsen Assignee: Claus Ibsen Priority: Minor Fix For: 2.14.1, 2.15.0, 2.13.4 See nabble http://camel.465427.n5.nabble.com/Problems-configuring-FileIdempotentRepository-tp5758212.html The file store should be created on startup so the file store is always available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7989) FileIdempotentRepository should create the file store on startup
[ https://issues.apache.org/jira/browse/CAMEL-7989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7989. Resolution: Fixed > FileIdempotentRepository should create the file store on startup > > > Key: CAMEL-7989 > URL: https://issues.apache.org/jira/browse/CAMEL-7989 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.13.3, 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.14.1, 2.15.0, 2.13.4 > > > See nabble > http://camel.465427.n5.nabble.com/Problems-configuring-FileIdempotentRepository-tp5758212.html > The file store should be created on startup so the file store is always > available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7988) file consumer - Should call abort in case read lock cannot be acquired if exception was thrown
[ https://issues.apache.org/jira/browse/CAMEL-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7988. Resolution: Fixed > file consumer - Should call abort in case read lock cannot be acquired if > exception was thrown > -- > > Key: CAMEL-7988 > URL: https://issues.apache.org/jira/browse/CAMEL-7988 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.13.3, 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.14.1, 2.15.0, 2.13.4 > > > See nabble > http://camel.465427.n5.nabble.com/Possible-issue-with-FileLockExclusiveReadLockStrategy-leaves-orphaned-camelLock-file-tp5758142.html > This could cause a .camelLock orphaned file to be there causing the file to > not be eligible for consuming on next poll. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7950) SJMS's Producers creates a new session per message request, this is both a performance issue and problem when using transactions
[ https://issues.apache.org/jira/browse/CAMEL-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193062#comment-14193062 ] Claus Ibsen commented on CAMEL-7950: Have you configured a connection pool? You need to use that for higher performance. > SJMS's Producers creates a new session per message request, this is both a > performance issue and problem when using transactions > > > Key: CAMEL-7950 > URL: https://issues.apache.org/jira/browse/CAMEL-7950 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside > > SJMS's Producers creates a new Session per message request, this is both a > performance issue and a problem when using transactions. > Sessions should be cached in ThreadLocal for performance reasons. Of course > you may want to limit the total number of cached sessions or even implement a > stack/queue of sessions to reuse. As long as a new session isn't created for > every single message produced to a Queue/Topic. > Second the same session should be used for any consumption and production to > any queues by a thread when transactions are enabled. If a single route is > consuming from JMS and producing to JMS, one would expect the same session to > be used to provide atomic consumption and production to the queues/topics > involved. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7908) Add a DestinationCreationStrategy to the SJMS component
[ https://issues.apache.org/jira/browse/CAMEL-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193166#comment-14193166 ] Claus Ibsen commented on CAMEL-7908: The patch does remove a bunch of api and code, and thus really only applicable for master branch. And therefore you would need to wait for Camel 2.15 release. Maybe you can create a patch that changes less and be better suitable for patching 2.14.x etc. > Add a DestinationCreationStrategy to the SJMS component > --- > > Key: CAMEL-7908 > URL: https://issues.apache.org/jira/browse/CAMEL-7908 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside >Priority: Minor > Attachments: unnamed2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Add a DestinationCreationStrategy to the SJMS component > JMS implementations like HornetQ do not allow dynamic queue/topic creation > via the pure JMS API's. Extending SJMS with a DestinationCreationStrategy > would allow one to replace the DefaultDestinationCreationStrategy with a > provider specific one that in the case of HornetQ dynamically creates the > queue/topic using the correct management API. > Implementation note: > JmsObjectFactory::createMessageProducer would be modified to supply a > DestinationCreateionStrategy, it would then use this to obtain Destination's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7908) Add a DestinationCreationStrategy to the SJMS component
[ https://issues.apache.org/jira/browse/CAMEL-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193167#comment-14193167 ] Claus Ibsen commented on CAMEL-7908: We also appreciate if there is unit tests that covers the new functionality, such as using a custom strategy. So please add an unit test that does that. > Add a DestinationCreationStrategy to the SJMS component > --- > > Key: CAMEL-7908 > URL: https://issues.apache.org/jira/browse/CAMEL-7908 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside >Priority: Minor > Attachments: unnamed2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Add a DestinationCreationStrategy to the SJMS component > JMS implementations like HornetQ do not allow dynamic queue/topic creation > via the pure JMS API's. Extending SJMS with a DestinationCreationStrategy > would allow one to replace the DefaultDestinationCreationStrategy with a > provider specific one that in the case of HornetQ dynamically creates the > queue/topic using the correct management API. > Implementation note: > JmsObjectFactory::createMessageProducer would be modified to supply a > DestinationCreateionStrategy, it would then use this to obtain Destination's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7908) Add a DestinationCreationStrategy to the SJMS component
[ https://issues.apache.org/jira/browse/CAMEL-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7908: --- Fix Version/s: 2.15.0 > Add a DestinationCreationStrategy to the SJMS component > --- > > Key: CAMEL-7908 > URL: https://issues.apache.org/jira/browse/CAMEL-7908 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside >Priority: Minor > Fix For: 2.15.0 > > Attachments: unnamed2.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Add a DestinationCreationStrategy to the SJMS component > JMS implementations like HornetQ do not allow dynamic queue/topic creation > via the pure JMS API's. Extending SJMS with a DestinationCreationStrategy > would allow one to replace the DefaultDestinationCreationStrategy with a > provider specific one that in the case of HornetQ dynamically creates the > queue/topic using the correct management API. > Implementation note: > JmsObjectFactory::createMessageProducer would be modified to supply a > DestinationCreateionStrategy, it would then use this to obtain Destination's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7908) Add a DestinationCreationStrategy to the SJMS component
[ https://issues.apache.org/jira/browse/CAMEL-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7908: --- Remaining Estimate: (was: 48h) Original Estimate: (was: 48h) > Add a DestinationCreationStrategy to the SJMS component > --- > > Key: CAMEL-7908 > URL: https://issues.apache.org/jira/browse/CAMEL-7908 > Project: Camel > Issue Type: Improvement > Components: camel-sjms >Affects Versions: 2.14.0 >Reporter: Aaron Whiteside >Priority: Minor > Fix For: 2.15.0 > > Attachments: unnamed2.patch > > > Add a DestinationCreationStrategy to the SJMS component > JMS implementations like HornetQ do not allow dynamic queue/topic creation > via the pure JMS API's. Extending SJMS with a DestinationCreationStrategy > would allow one to replace the DefaultDestinationCreationStrategy with a > provider specific one that in the case of HornetQ dynamically creates the > queue/topic using the correct management API. > Implementation note: > JmsObjectFactory::createMessageProducer would be modified to supply a > DestinationCreateionStrategy, it would then use this to obtain Destination's. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7986) Route disappears with routeId set to "route1"
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7986:
---
Fix Version/s: 2.13.4
2.15.0
2.14.1
> Route disappears with routeId set to "route1"
> -
>
> Key: CAMEL-7986
> URL: https://issues.apache.org/jira/browse/CAMEL-7986
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Peter Keller
> Fix For: 2.14.1, 2.15.0, 2.13.4
>
>
> With below route configuration with {{routeId}} defined as {{route1}},
> {{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
> will auto-generate a {{routeId}} with format as {{route}} + count for you if
> you didn't define it. This seems to cause some routes to be missed.
> Route definitions:
> {code}
> from("direct:start1")
> .routeId("route1")
> .log("route1: ${body}");
> from("direct:start2")
> .routeId("route2")
> .log("route2: ${body}");
> from("direct:start3") // no route id!
> .log("route3: ${body}");
> {code}
> Testing:
> {code}
> ProducerTemplate template = context.createProducerTemplate();
> template.sendBody("direct:start1", "World!");
> template.sendBody("direct:start2", "World!");
> {code}
> This leads to following exception:
> {quote}
> Caused by:
> org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
> consumers available on endpoint: Endpoint[direct://start1]
> {quote}
> If the {{direct:start3}} route is deleted or the ID {{"route1"}} is renamed,
> then everything works as expected.
> See
> http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7986) Route disappears with routeId set to "route1"
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-7986:
--
Assignee: Claus Ibsen
> Route disappears with routeId set to "route1"
> -
>
> Key: CAMEL-7986
> URL: https://issues.apache.org/jira/browse/CAMEL-7986
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Peter Keller
>Assignee: Claus Ibsen
> Fix For: 2.14.1, 2.15.0, 2.13.4
>
>
> With below route configuration with {{routeId}} defined as {{route1}},
> {{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
> will auto-generate a {{routeId}} with format as {{route}} + count for you if
> you didn't define it. This seems to cause some routes to be missed.
> Route definitions:
> {code}
> from("direct:start1")
> .routeId("route1")
> .log("route1: ${body}");
> from("direct:start2")
> .routeId("route2")
> .log("route2: ${body}");
> from("direct:start3") // no route id!
> .log("route3: ${body}");
> {code}
> Testing:
> {code}
> ProducerTemplate template = context.createProducerTemplate();
> template.sendBody("direct:start1", "World!");
> template.sendBody("direct:start2", "World!");
> {code}
> This leads to following exception:
> {quote}
> Caused by:
> org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
> consumers available on endpoint: Endpoint[direct://start1]
> {quote}
> If the {{direct:start3}} route is deleted or the ID {{"route1"}} is renamed,
> then everything works as expected.
> See
> http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7990) IdempotentConsumer - If no messageId should allow Camel error handler to react
Claus Ibsen created CAMEL-7990: -- Summary: IdempotentConsumer - If no messageId should allow Camel error handler to react Key: CAMEL-7990 URL: https://issues.apache.org/jira/browse/CAMEL-7990 Project: Camel Issue Type: Bug Components: camel-core, eip Affects Versions: 2.14.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.14.1, 2.15.0, 2.13.4 See SO http://stackoverflow.com/questions/26453348/camel-onexception-doesnt-catch-nomessageidexception-of-idempotentconsumer The idempotent consumer should set the exchange on the exchange and invoke the callback, that is an internal routing engine bug in the implementation of that eip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7990) IdempotentConsumer - If no messageId should allow Camel error handler to react
[ https://issues.apache.org/jira/browse/CAMEL-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7990. Resolution: Fixed > IdempotentConsumer - If no messageId should allow Camel error handler to react > -- > > Key: CAMEL-7990 > URL: https://issues.apache.org/jira/browse/CAMEL-7990 > Project: Camel > Issue Type: Bug > Components: camel-core, eip >Affects Versions: 2.14.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.14.1, 2.15.0, 2.13.4 > > > See SO > http://stackoverflow.com/questions/26453348/camel-onexception-doesnt-catch-nomessageidexception-of-idempotentconsumer > The idempotent consumer should set the exchange on the exchange and invoke > the callback, that is an internal routing engine bug in the implementation of > that eip. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7986) Route disappears with routeId set to "route1"
[
https://issues.apache.org/jira/browse/CAMEL-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7986.
Resolution: Fixed
> Route disappears with routeId set to "route1"
> -
>
> Key: CAMEL-7986
> URL: https://issues.apache.org/jira/browse/CAMEL-7986
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.14.0
>Reporter: Peter Keller
>Assignee: Claus Ibsen
> Fix For: 2.14.1, 2.15.0, 2.13.4
>
>
> With below route configuration with {{routeId}} defined as {{route1}},
> {{route2}} and intentionally omitted {{routeId}} for the 3rd route, Camel
> will auto-generate a {{routeId}} with format as {{route}} + count for you if
> you didn't define it. This seems to cause some routes to be missed.
> Route definitions:
> {code}
> from("direct:start1")
> .routeId("route1")
> .log("route1: ${body}");
> from("direct:start2")
> .routeId("route2")
> .log("route2: ${body}");
> from("direct:start3") // no route id!
> .log("route3: ${body}");
> {code}
> Testing:
> {code}
> ProducerTemplate template = context.createProducerTemplate();
> template.sendBody("direct:start1", "World!");
> template.sendBody("direct:start2", "World!");
> {code}
> This leads to following exception:
> {quote}
> Caused by:
> org.apache.camel.component.direct.DirectConsumerNotAvailableException: No
> consumers available on endpoint: Endpoint[direct://start1]
> {quote}
> If the {{direct:start3}} route is deleted or the ID {{"route1"}} is renamed,
> then everything works as expected.
> See
> http://stackoverflow.com/questions/26646881/route-is-not-detected-when-route-id-is-not-assigned-does-camelcontext-loses-the/26673144#26673144
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7983) Using named query parameters doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7983.
Resolution: Cannot Reproduce
Fix Version/s: 2.15.0
Assignee: Claus Ibsen
Works fine. I cannot reproduce the issue, I get an error if I set an invalid
named parameter, such as 'foo'
{code}
[mel-1) thread #1 - timer://foo] TimerConsumer WARN Error
processing exchange. Exchange[Message: {amount=3, id=0, description=ActiveMQ in
Action, item=222}]. Caused by: [org.apache.camel.RuntimeExchangeException -
Cannot find key [foo] in message body or headers to use when setting named
parameter in query [insert into orders (id, item, amount, description,
processed) values (:?id, :?foo, :?amount, :?description, false)] on the
exchange: Exchange[Message: {amount=3, id=0, description=ActiveMQ in Action,
item=222}]]
{code}
> Using named query parameters doesn't work
> -
>
> Key: CAMEL-7983
> URL: https://issues.apache.org/jira/browse/CAMEL-7983
> Project: Camel
> Issue Type: Bug
> Components: camel-sql
>Affects Versions: 2.14.0
> Environment: Windows7, ActiveMq 5.10, Camel 2.14, MySQL Server 5.6
>Reporter: Josef Awad
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.15.0
>
>
> Reference:
> http://camel.465427.n5.nabble.com/Using-named-query-parameters-td5758002.html
> Excerpt:
> Under http://camel.apache.org/sql-example.html at the very bottom it says:
> Notice in the SQL queries below we use named parameters which must start with
> prefix ':#' and then the name, eg :#amount. Then Camel will bind that
> parameter with the given name, from the
> message body (if its a java.util.Map) or from a message header with the name.
> If none parameter could be found, Camel throws an exception.
> If I set a wrong parameter in the sql.properties I don't get any exception:
> sql.insertPosition=insert into mydb.test (col1) values (':#DoesNotExist')
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7968) Container has undefined concurrency behaviour
[ https://issues.apache.org/jira/browse/CAMEL-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7968. Resolution: Fixed Fix Version/s: 2.15.0 Assignee: Claus Ibsen Added more details in the javadoc that Container is not thread-safe, which has never been the intention either. > Container has undefined concurrency behaviour > - > > Key: CAMEL-7968 > URL: https://issues.apache.org/jira/browse/CAMEL-7968 > Project: Camel > Issue Type: Bug >Affects Versions: 2.14.0 >Reporter: Thomas Diesler >Assignee: Claus Ibsen > Fix For: 2.15.0 > > > The implementation of Container.Instance is not ThreadSafe. It is also not > defined what happens when multiple Containers race on the singleton. > Instead of using a Container singleton approach. It might be better to have a > singleton ContainerRegistry that can handle concurrent/multiple Containers -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7970) Container does not see the unregister event
[ https://issues.apache.org/jira/browse/CAMEL-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193758#comment-14193758 ] Claus Ibsen commented on CAMEL-7970: Yeah unfortunately that breaks the API. You can use EventNotifer to register a callback to get notified when the context is stopping/stopped. > Container does not see the unregister event > --- > > Key: CAMEL-7970 > URL: https://issues.apache.org/jira/browse/CAMEL-7970 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Thomas Diesler > Fix For: 3.0.0 > > > Clients of the Container SPI see contexts being added but not removed. In > wildfly we expose every context as an msc service to allow for service > dependencies on it. When a context gets unregistered we must also unregister > the msc service. > unmanage(CamelContext) should probably be exposed in the same way as > manage(CamelContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7970) Container does not see the unregister event
[ https://issues.apache.org/jira/browse/CAMEL-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7970: --- Issue Type: Improvement (was: Bug) > Container does not see the unregister event > --- > > Key: CAMEL-7970 > URL: https://issues.apache.org/jira/browse/CAMEL-7970 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Thomas Diesler > Fix For: 3.0.0 > > > Clients of the Container SPI see contexts being added but not removed. In > wildfly we expose every context as an msc service to allow for service > dependencies on it. When a context gets unregistered we must also unregister > the msc service. > unmanage(CamelContext) should probably be exposed in the same way as > manage(CamelContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7970) Container does not see the unregister event
[ https://issues.apache.org/jira/browse/CAMEL-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7970: --- Component/s: camel-core > Container does not see the unregister event > --- > > Key: CAMEL-7970 > URL: https://issues.apache.org/jira/browse/CAMEL-7970 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Thomas Diesler > Fix For: 3.0.0 > > > Clients of the Container SPI see contexts being added but not removed. In > wildfly we expose every context as an msc service to allow for service > dependencies on it. When a context gets unregistered we must also unregister > the msc service. > unmanage(CamelContext) should probably be exposed in the same way as > manage(CamelContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7970) Container does not see the unregister event
[ https://issues.apache.org/jira/browse/CAMEL-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7970: --- Fix Version/s: 3.0.0 > Container does not see the unregister event > --- > > Key: CAMEL-7970 > URL: https://issues.apache.org/jira/browse/CAMEL-7970 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Thomas Diesler > Fix For: 3.0.0 > > > Clients of the Container SPI see contexts being added but not removed. In > wildfly we expose every context as an msc service to allow for service > dependencies on it. When a context gets unregistered we must also unregister > the msc service. > unmanage(CamelContext) should probably be exposed in the same way as > manage(CamelContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7970) Container does not see the unregister event
[ https://issues.apache.org/jira/browse/CAMEL-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193759#comment-14193759 ] Claus Ibsen commented on CAMEL-7970: We can add a unmanage method to org.apache.camel.spi.Container in Camel 3.0. > Container does not see the unregister event > --- > > Key: CAMEL-7970 > URL: https://issues.apache.org/jira/browse/CAMEL-7970 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.14.0 >Reporter: Thomas Diesler > Fix For: 3.0.0 > > > Clients of the Container SPI see contexts being added but not removed. In > wildfly we expose every context as an msc service to allow for service > dependencies on it. When a context gets unregistered we must also unregister > the msc service. > unmanage(CamelContext) should probably be exposed in the same way as > manage(CamelContext) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7969) Container sees Context prematurely (with default name)
[
https://issues.apache.org/jira/browse/CAMEL-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7969.
Resolution: Won't Fix
Fix Version/s: 2.15.0
Assignee: Claus Ibsen
> Container sees Context prematurely (with default name)
> --
>
> Key: CAMEL-7969
> URL: https://issues.apache.org/jira/browse/CAMEL-7969
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.14.0
>Reporter: Thomas Diesler
>Assignee: Claus Ibsen
> Fix For: 2.15.0
>
>
> In the case of SpringCamelContext we have this code
> {code}
> protected SpringCamelContext createContext() {
> SpringCamelContext ctx = newCamelContext();
> ctx.setName(getId());
> return ctx;
> }
> {code}
> The Container singleton is however called from the DefaultCamelContext ctor
> (i.e. before the name is initialised properly)
> CrossRef: https://github.com/tdiesler/wildfly-camel/issues/16
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7962) Pipeline factories names on netty4 component
[ https://issues.apache.org/jira/browse/CAMEL-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7962: --- Issue Type: Improvement (was: Bug) > Pipeline factories names on netty4 component > > > Key: CAMEL-7962 > URL: https://issues.apache.org/jira/browse/CAMEL-7962 > Project: Camel > Issue Type: Improvement > Components: camel-netty4 >Affects Versions: 2.14.0 >Reporter: Yaron A >Priority: Trivial > > As ServerPipelineFactory & ClientPipelineFactory classes are now named as > ServerInitializerFactory & ClientInitializerFactory, I thought that it will > make sense to call the matching netty4 component parameter names as > serverInitializerFactory & clientInitializerFactory (and also to fix the > relevant documentations) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7962) Pipeline factories names on netty4 component
[ https://issues.apache.org/jira/browse/CAMEL-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7962: --- Affects Version/s: 2.14.0 > Pipeline factories names on netty4 component > > > Key: CAMEL-7962 > URL: https://issues.apache.org/jira/browse/CAMEL-7962 > Project: Camel > Issue Type: Improvement > Components: camel-netty4 >Affects Versions: 2.14.0 >Reporter: Yaron A >Priority: Trivial > > As ServerPipelineFactory & ClientPipelineFactory classes are now named as > ServerInitializerFactory & ClientInitializerFactory, I thought that it will > make sense to call the matching netty4 component parameter names as > serverInitializerFactory & clientInitializerFactory (and also to fix the > relevant documentations) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7962) Pipeline factories names on netty4 component
[ https://issues.apache.org/jira/browse/CAMEL-7962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7962. Resolution: Fixed Fix Version/s: 2.15.0 Assignee: Claus Ibsen Yeah good idea. I have deprecated the old option names, and introduce the ne netty4 names, and fixed the netty4 docs also. > Pipeline factories names on netty4 component > > > Key: CAMEL-7962 > URL: https://issues.apache.org/jira/browse/CAMEL-7962 > Project: Camel > Issue Type: Improvement > Components: camel-netty4 >Affects Versions: 2.14.0 >Reporter: Yaron A >Assignee: Claus Ibsen >Priority: Trivial > Fix For: 2.15.0 > > > As ServerPipelineFactory & ClientPipelineFactory classes are now named as > ServerInitializerFactory & ClientInitializerFactory, I thought that it will > make sense to call the matching netty4 component parameter names as > serverInitializerFactory & clientInitializerFactory (and also to fix the > relevant documentations) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7834: --- Fix Version/s: 2.15.0 > create a docker events endpoint > --- > > Key: CAMEL-7834 > URL: https://issues.apache.org/jira/browse/CAMEL-7834 > Project: Camel > Issue Type: New Feature > Components: camel-docker >Reporter: james strachan >Assignee: Willem Jiang > Fix For: 2.15.0 > > > Docker provides a REST API to query events (for containers starting and > stopping etc): > https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events > it'd be nice to support a simple camel component to make it easier to consume > docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7834: --- Component/s: camel-docker > create a docker events endpoint > --- > > Key: CAMEL-7834 > URL: https://issues.apache.org/jira/browse/CAMEL-7834 > Project: Camel > Issue Type: New Feature > Components: camel-docker >Reporter: james strachan >Assignee: Willem Jiang > Fix For: 2.15.0 > > > Docker provides a REST API to query events (for containers starting and > stopping etc): > https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events > it'd be nice to support a simple camel component to make it easier to consume > docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7834. Resolution: Fixed Thanks. Added the docs to the wiki > create a docker events endpoint > --- > > Key: CAMEL-7834 > URL: https://issues.apache.org/jira/browse/CAMEL-7834 > Project: Camel > Issue Type: New Feature > Components: camel-docker >Reporter: james strachan >Assignee: Willem Jiang > Fix For: 2.15.0 > > > Docker provides a REST API to query events (for containers starting and > stopping etc): > https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events > it'd be nice to support a simple camel component to make it easier to consume > docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7943) Add jackson core dependency to camel-dropbox pom
[ https://issues.apache.org/jira/browse/CAMEL-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7943: --- Issue Type: Task (was: Bug) > Add jackson core dependency to camel-dropbox pom > > > Key: CAMEL-7943 > URL: https://issues.apache.org/jira/browse/CAMEL-7943 > Project: Camel > Issue Type: Task >Reporter: Kevin Earls >Priority: Minor > > camel-dropbox has a dependency on the dropbox sdks, which has a dependency on > jackson-core [2.2,2.3). This can cause build failures > such as "Failed to execute goal on project camel-dropbox: Could not resolve > dependencies for project > org.apache.camel:camel-dropbox:bundle:2.14.0.redhat-SNAPSHOT: Could not find > artifact com.fasterxml.jackson.core:jackson-core:jar:2.3.0-rc2-SNAPSHOT -> > [Help 2]" depending on what repos you are using. > We should add the jackson-core dependency directly to this pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7943) Add jackson core dependency to camel-dropbox pom
[ https://issues.apache.org/jira/browse/CAMEL-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7943: --- Component/s: el-dropbox > Add jackson core dependency to camel-dropbox pom > > > Key: CAMEL-7943 > URL: https://issues.apache.org/jira/browse/CAMEL-7943 > Project: Camel > Issue Type: Task > Components: el-dropbox >Reporter: Kevin Earls >Priority: Minor > Fix For: 2.14.1, 2.15.0 > > > camel-dropbox has a dependency on the dropbox sdks, which has a dependency on > jackson-core [2.2,2.3). This can cause build failures > such as "Failed to execute goal on project camel-dropbox: Could not resolve > dependencies for project > org.apache.camel:camel-dropbox:bundle:2.14.0.redhat-SNAPSHOT: Could not find > artifact com.fasterxml.jackson.core:jackson-core:jar:2.3.0-rc2-SNAPSHOT -> > [Help 2]" depending on what repos you are using. > We should add the jackson-core dependency directly to this pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7943) Add jackson core dependency to camel-dropbox pom
[ https://issues.apache.org/jira/browse/CAMEL-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7943. Resolution: Fixed Fix Version/s: 2.15.0 2.14.1 > Add jackson core dependency to camel-dropbox pom > > > Key: CAMEL-7943 > URL: https://issues.apache.org/jira/browse/CAMEL-7943 > Project: Camel > Issue Type: Task > Components: el-dropbox >Reporter: Kevin Earls >Priority: Minor > Fix For: 2.14.1, 2.15.0 > > > camel-dropbox has a dependency on the dropbox sdks, which has a dependency on > jackson-core [2.2,2.3). This can cause build failures > such as "Failed to execute goal on project camel-dropbox: Could not resolve > dependencies for project > org.apache.camel:camel-dropbox:bundle:2.14.0.redhat-SNAPSHOT: Could not find > artifact com.fasterxml.jackson.core:jackson-core:jar:2.3.0-rc2-SNAPSHOT -> > [Help 2]" depending on what repos you are using. > We should add the jackson-core dependency directly to this pom. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7906) camel-restlet component receive error: "405 Method Not Allowed" from other restlet for one level URL with template in the end
[
https://issues.apache.org/jira/browse/CAMEL-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193816#comment-14193816
]
Claus Ibsen commented on CAMEL-7906:
Its a bug in restlet that in {{org.restlet.util.RouteList#getBest}} that doesnt
find the best. There uri that has 100% match isn't picked over the uri that is
99% matched. They both get a score of 1.0, and restlet picks the 1st one.
> camel-restlet component receive error: "405 Method Not Allowed" from other
> restlet for one level URL with template in the end
> -
>
> Key: CAMEL-7906
> URL: https://issues.apache.org/jira/browse/CAMEL-7906
> Project: Camel
> Issue Type: Bug
> Components: camel-restlet
>Reporter: Sergey Semka
> Attachments: BugInRestletMultiRoutesEndpointTest.java
>
>
> Description of bug #1:
> We had to receive error: "405 Method Not Allowed"
> because the invoked restlet (route) does not have the requested POST method.
> (it has restletMethods=GET).
> But we do not get such an error. We get response status = 200.
> Because we get into the rout of another restlet (which ends in a template).
> We request the following URL:
>http://localhost:1101/users/{id}/test/search ,restletMethods=GET
> But we get to URL:
>http://localhost:1101/users/{id}/test/{username}
> ,restletMethods=PUT,POST
> Description of bug #2:
> There is restlet (route): http://localhost:1101/users/{id}/test/search, which
> supports restletMethods GET but when we request it, we get the following
> error: "405 Method Not Allowed"
> tests for confirmation of existence of two bugs in camel-restlet:
> Link for file in Google Drive:
> https://drive.google.com/file/d/0B0DfsrbRTR2tamJXNTEyVXJPVHc/view?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-7906) camel-restlet component receive error: "405 Method Not Allowed" from other restlet for one level URL with template in the end
[
https://issues.apache.org/jira/browse/CAMEL-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-7906:
--
Assignee: Claus Ibsen
> camel-restlet component receive error: "405 Method Not Allowed" from other
> restlet for one level URL with template in the end
> -
>
> Key: CAMEL-7906
> URL: https://issues.apache.org/jira/browse/CAMEL-7906
> Project: Camel
> Issue Type: Bug
> Components: camel-restlet
>Reporter: Sergey Semka
>Assignee: Claus Ibsen
> Attachments: BugInRestletMultiRoutesEndpointTest.java
>
>
> Description of bug #1:
> We had to receive error: "405 Method Not Allowed"
> because the invoked restlet (route) does not have the requested POST method.
> (it has restletMethods=GET).
> But we do not get such an error. We get response status = 200.
> Because we get into the rout of another restlet (which ends in a template).
> We request the following URL:
>http://localhost:1101/users/{id}/test/search ,restletMethods=GET
> But we get to URL:
>http://localhost:1101/users/{id}/test/{username}
> ,restletMethods=PUT,POST
> Description of bug #2:
> There is restlet (route): http://localhost:1101/users/{id}/test/search, which
> supports restletMethods GET but when we request it, we get the following
> error: "405 Method Not Allowed"
> tests for confirmation of existence of two bugs in camel-restlet:
> Link for file in Google Drive:
> https://drive.google.com/file/d/0B0DfsrbRTR2tamJXNTEyVXJPVHc/view?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7995) Route model - Keep the {{ }} placeholders and allow api to get the model with the resolved values
Claus Ibsen created CAMEL-7995:
--
Summary: Route model - Keep the {{ }} placeholders and allow api
to get the model with the resolved values
Key: CAMEL-7995
URL: https://issues.apache.org/jira/browse/CAMEL-7995
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Claus Ibsen
Fix For: 3.0.0, Future
When you define routes using {{ }} placeholders, they get resolved when Camel
builds the runtime route. And the route model gets updated with the resolved
values, eg so {{ }} gets replaced with the value.
So when you dump the route model as xml (eg as source) then you loose the {{ }}
placeholders and see the actual values.
We should allow to keep the {{ }} so the route model is 100% as designed, but
we should also store the resolved values that the runtime route is using, so
you can see those values as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7995) Route model - Keep the {{ }} placeholders and allow api to get the model with the resolved values
[
https://issues.apache.org/jira/browse/CAMEL-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195886#comment-14195886
]
Claus Ibsen commented on CAMEL-7995:
For example you may develop this route
{code}
http://camel.apache.org/schema/blueprint";>
{code}
Which at runtime becomes dumped as source as
{code}
http://camel.apache.org/schema/spring"; id="route1">
{code}
So what we want is being able to dump the route as source using the original {{
}} placeholders. That would require an option / new API operation to specify
with or without the {{ }}.
> Route model - Keep the {{ }} placeholders and allow api to get the model with
> the resolved values
> -
>
> Key: CAMEL-7995
> URL: https://issues.apache.org/jira/browse/CAMEL-7995
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
> Fix For: 3.0.0, Future
>
>
> When you define routes using {{ }} placeholders, they get resolved when Camel
> builds the runtime route. And the route model gets updated with the resolved
> values, eg so {{ }} gets replaced with the value.
> So when you dump the route model as xml (eg as source) then you loose the {{
> }} placeholders and see the actual values.
> We should allow to keep the {{ }} so the route model is 100% as designed, but
> we should also store the resolved values that the runtime route is using, so
> you can see those values as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-3214) Property placeholder support for multiple inputs to a route
[
https://issues.apache.org/jira/browse/CAMEL-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-3214.
Resolution: Won't Fix
Assignee: Claus Ibsen
We want Camel 3.0 to be only one input per route
> Property placeholder support for multiple inputs to a route
>
>
> Key: CAMEL-3214
> URL: https://issues.apache.org/jira/browse/CAMEL-3214
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
>Affects Versions: 2.4.0
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.0.0
>
>
> If you have a route and you have externalized the incoming endpoint uri using
> property placeholder
> {code}
> from("{{inputA}}").to("xxx");
> {code}
> Then you may want to support that {{inputA}} can contain 1..n endpoints.
> {code}
> inputA=direct:start
> inputA=activemq:queue:foo,cxf:bean:foo
> {code}
> The placeholder can contain multiple entries separated by a token such as
> comma.
> All we essentially need is to use the ObjectHelper.createIterator on the
> value and then add inputs to the route.
> It should trim the values so you can have space between the comma, so its
> easier to read.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7995) Route model - Keep the {{ }} placeholders and allow api to get the model with the resolved values
[
https://issues.apache.org/jira/browse/CAMEL-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7995.
Resolution: Won't Fix
Assignee: Claus Ibsen
> Route model - Keep the {{ }} placeholders and allow api to get the model with
> the resolved values
> -
>
> Key: CAMEL-7995
> URL: https://issues.apache.org/jira/browse/CAMEL-7995
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
> Fix For: 3.0.0, Future
>
>
> When you define routes using {{ }} placeholders, they get resolved when Camel
> builds the runtime route. And the route model gets updated with the resolved
> values, eg so {{ }} gets replaced with the value.
> So when you dump the route model as xml (eg as source) then you loose the {{
> }} placeholders and see the actual values.
> We should allow to keep the {{ }} so the route model is 100% as designed, but
> we should also store the resolved values that the runtime route is using, so
> you can see those values as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-6099) File producer - See if we can support chmod option like ftp producer
[ https://issues.apache.org/jira/browse/CAMEL-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198810#comment-14198810 ] Claus Ibsen commented on CAMEL-6099: Is the documentation updated at? http://camel.apache.org/file2 > File producer - See if we can support chmod option like ftp producer > > > Key: CAMEL-6099 > URL: https://issues.apache.org/jira/browse/CAMEL-6099 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen > Fix For: 2.15.0 > > > See > http://stackoverflow.com/questions/15006065/write-file-with-camel-and-set-chmod > There is some links on that to other SO about how to set chmod using the java > file api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7993) Log statement for chmod in ftp component is missing {}
[
https://issues.apache.org/jira/browse/CAMEL-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7993:
---
Issue Type: Task (was: Bug)
> Log statement for chmod in ftp component is missing {}
> --
>
> Key: CAMEL-7993
> URL: https://issues.apache.org/jira/browse/CAMEL-7993
> Project: Camel
> Issue Type: Task
> Components: camel-ftp
>Reporter: Kevin Earls
>Priority: Trivial
>
> SftpOperations.java contains this log statement:
> LOG.trace("Setting chmod: {} on file: ", mode, targetName);
> It needs another set of brackets after file, otherwise it does not report the
> file name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7969) Container sees Context prematurely (with default name)
[
https://issues.apache.org/jira/browse/CAMEL-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7969.
Resolution: Won't Fix
> Container sees Context prematurely (with default name)
> --
>
> Key: CAMEL-7969
> URL: https://issues.apache.org/jira/browse/CAMEL-7969
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.14.0
>Reporter: Thomas Diesler
>Assignee: Claus Ibsen
> Fix For: 2.15.0
>
>
> In the case of SpringCamelContext we have this code
> {code}
> protected SpringCamelContext createContext() {
> SpringCamelContext ctx = newCamelContext();
> ctx.setName(getId());
> return ctx;
> }
> {code}
> The Container singleton is however called from the DefaultCamelContext ctor
> (i.e. before the name is initialised properly)
> CrossRef: https://github.com/tdiesler/wildfly-camel/issues/16
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7993) Log statement for chmod in ftp component is missing {}
[
https://issues.apache.org/jira/browse/CAMEL-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7993.
Resolution: Fixed
Fix Version/s: 2.15.0
Assignee: Claus Ibsen
Thanks for the PR
> Log statement for chmod in ftp component is missing {}
> --
>
> Key: CAMEL-7993
> URL: https://issues.apache.org/jira/browse/CAMEL-7993
> Project: Camel
> Issue Type: Task
> Components: camel-ftp
>Reporter: Kevin Earls
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 2.15.0
>
>
> SftpOperations.java contains this log statement:
> LOG.trace("Setting chmod: {} on file: ", mode, targetName);
> It needs another set of brackets after file, otherwise it does not report the
> file name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-7987) Distro -javadoc JARs has malfuncted .css stylesheet files
[ https://issues.apache.org/jira/browse/CAMEL-7987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-7987. Resolution: Fixed Fix Version/s: 2.15.0 > Distro -javadoc JARs has malfuncted .css stylesheet files > - > > Key: CAMEL-7987 > URL: https://issues.apache.org/jira/browse/CAMEL-7987 > Project: Camel > Issue Type: Task > Components: build system >Affects Versions: 2.14.0 >Reporter: Claus Ibsen >Assignee: Willem Jiang > Fix For: 2.15.0 > > > For example camel-core -javadoc JAR has a stylesheet.css file embedded that > is a bit wrong as the Apache header in the top seems to have cut off some of > the css file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7991) Add MultiPartUpload functionality to S3Producer
[ https://issues.apache.org/jira/browse/CAMEL-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198827#comment-14198827 ] Claus Ibsen commented on CAMEL-7991: Thanks for the patch. We need the new options documented at http://camel.apache.org/aws > Add MultiPartUpload functionality to S3Producer > --- > > Key: CAMEL-7991 > URL: https://issues.apache.org/jira/browse/CAMEL-7991 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Andreas C. Osowski >Assignee: Willem Jiang > Fix For: 2.15.0 > > Attachments: patch-s3-producer-multipart-upload-fix.patch > > > The current S3 Producer implementation does not use S3's MultiPartUpload > functionality. Therefore, the whole data blob needs to be buffered in memory > before it can be uploaded to S3. > Using MultiPartUpload, the blob can be uploaded in chunks thereby drastically > reducing the required memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7991) Add MultiPartUpload functionality to S3Producer
[ https://issues.apache.org/jira/browse/CAMEL-7991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7991: --- Fix Version/s: 2.15.0 > Add MultiPartUpload functionality to S3Producer > --- > > Key: CAMEL-7991 > URL: https://issues.apache.org/jira/browse/CAMEL-7991 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Andreas C. Osowski >Assignee: Willem Jiang > Fix For: 2.15.0 > > Attachments: patch-s3-producer-multipart-upload-fix.patch > > > The current S3 Producer implementation does not use S3's MultiPartUpload > functionality. Therefore, the whole data blob needs to be buffered in memory > before it can be uploaded to S3. > Using MultiPartUpload, the blob can be uploaded in chunks thereby drastically > reducing the required memory. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7985) camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
[
https://issues.apache.org/jira/browse/CAMEL-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198830#comment-14198830
]
Claus Ibsen commented on CAMEL-7985:
[~gnt] wonder if you can do pojosr releases? Or can reach out to that community
to get a new pojosr release with this fix. Another way is to add a workaroud in
felix fileinstall to avoid that repearted logging, which does CPU spike. eg
when there is an exception the loop does not sleep for 1 sec which it otherwise
does by default, causing CPU spikes.
> camel-test-blueprint - Upgrading to newer felix fails with NPE in fileinstall
> -
>
> Key: CAMEL-7985
> URL: https://issues.apache.org/jira/browse/CAMEL-7985
> Project: Camel
> Issue Type: Improvement
> Components: camel-blueprint, camel-test
>Affects Versions: 2.14.0
>Reporter: Claus Ibsen
> Fix For: 2.15.0
>
> Attachments: Screen Shot 2014-10-30 at 11.44.58 AM.png
>
>
> We get a bunch of these errors during testing with osgi blueprint
> {code}
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> In main loop, we have serious trouble: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:303)
> {code}
> Run tests here
> {code}
> camel/tests/camel-blueprint-cxf-test (master)/$ mvn clean install
> {code}
> And upgrade Felix in parent/pom.xml
> {code}
> -1.4.0
> -3.2.6
> -3.2.2
> +1.8.0
> +3.4.2
> +3.4.2
> {code}
> And you get these NPEs.
> Maybe something needs to be fixed in camel-test-blueprint with that pojosr
> library, so bundle 0 is that system bundle, as the NPE is at:
> https://github.com/apache/felix/blame/trunk/fileinstall/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L303
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7906) camel-restlet component receive error: "405 Method Not Allowed" from other restlet for one level URL with template in the end
[
https://issues.apache.org/jira/browse/CAMEL-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198841#comment-14198841
]
Claus Ibsen commented on CAMEL-7906:
I think the logic in restlet is the correct place to improve so its getBest
deals with this. Its a non trivial problem how to match those template patterns
- when they clash with a /search and a {username} in the same position. In that
case /search should be picked over as you would not search for a person with a
username search. Also getBest does only template mating on the uri, and do not
take HTTP Method into consideration.
> camel-restlet component receive error: "405 Method Not Allowed" from other
> restlet for one level URL with template in the end
> -
>
> Key: CAMEL-7906
> URL: https://issues.apache.org/jira/browse/CAMEL-7906
> Project: Camel
> Issue Type: Bug
> Components: camel-restlet
>Reporter: Sergey Semka
>Assignee: Claus Ibsen
> Attachments: BugInRestletMultiRoutesEndpointTest.java
>
>
> Description of bug #1:
> We had to receive error: "405 Method Not Allowed"
> because the invoked restlet (route) does not have the requested POST method.
> (it has restletMethods=GET).
> But we do not get such an error. We get response status = 200.
> Because we get into the rout of another restlet (which ends in a template).
> We request the following URL:
>http://localhost:1101/users/{id}/test/search ,restletMethods=GET
> But we get to URL:
>http://localhost:1101/users/{id}/test/{username}
> ,restletMethods=PUT,POST
> Description of bug #2:
> There is restlet (route): http://localhost:1101/users/{id}/test/search, which
> supports restletMethods GET but when we request it, we get the following
> error: "405 Method Not Allowed"
> tests for confirmation of existence of two bugs in camel-restlet:
> Link for file in Google Drive:
> https://drive.google.com/file/d/0B0DfsrbRTR2tamJXNTEyVXJPVHc/view?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7906) camel-restlet component receive error: "405 Method Not Allowed" from other restlet for one level URL with template in the end
[
https://issues.apache.org/jira/browse/CAMEL-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198843#comment-14198843
]
Claus Ibsen commented on CAMEL-7906:
In your use-case you can swap the 2 routes, then the /search will be picked by
restlet.
> camel-restlet component receive error: "405 Method Not Allowed" from other
> restlet for one level URL with template in the end
> -
>
> Key: CAMEL-7906
> URL: https://issues.apache.org/jira/browse/CAMEL-7906
> Project: Camel
> Issue Type: Bug
> Components: camel-restlet
>Reporter: Sergey Semka
>Assignee: Claus Ibsen
> Attachments: BugInRestletMultiRoutesEndpointTest.java
>
>
> Description of bug #1:
> We had to receive error: "405 Method Not Allowed"
> because the invoked restlet (route) does not have the requested POST method.
> (it has restletMethods=GET).
> But we do not get such an error. We get response status = 200.
> Because we get into the rout of another restlet (which ends in a template).
> We request the following URL:
>http://localhost:1101/users/{id}/test/search ,restletMethods=GET
> But we get to URL:
>http://localhost:1101/users/{id}/test/{username}
> ,restletMethods=PUT,POST
> Description of bug #2:
> There is restlet (route): http://localhost:1101/users/{id}/test/search, which
> supports restletMethods GET but when we request it, we get the following
> error: "405 Method Not Allowed"
> tests for confirmation of existence of two bugs in camel-restlet:
> Link for file in Google Drive:
> https://drive.google.com/file/d/0B0DfsrbRTR2tamJXNTEyVXJPVHc/view?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7999) Camel Toolbox - Easy information about all Camel components and the release for tooling
Claus Ibsen created CAMEL-7999: -- Summary: Camel Toolbox - Easy information about all Camel components and the release for tooling Key: CAMEL-7999 URL: https://issues.apache.org/jira/browse/CAMEL-7999 Project: Camel Issue Type: New Feature Components: camel-core, jmx, tooling Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.15.0 A Camel release contains many components, and we have the ability to let components document which options they offer. Though there is currently a few shortcomings that can be improved - the component json schema is currently runtime generated, which requires to load the component and create an instance of it. Instead we should build-time generate it, which we do today with the camel apt compiler plugin. - we should include documentation about the option from the javadoc, that allows end users to fully document a component using plain java getter/settr with javadocs, and add those @UriParam annotations for the apt compiler to detect and leverage - add a module that embeds all these json schema files in a single module, and also other information, such as the xml schemas, and what else can be handy. Then there is a single module as a one stop shop for tooling and whatnot to gather information about a Camel release. - allow at runtime to explain an endpoint uri what the options in use are, eg as we got the json schema, we can add mbeans that can explain those options, than we can use in tooling, JMX, karaf commands etc. And also IDE editors etc - enrich the dsl xml to inject javadoc for the eips into the xml schema, so we have documented in the xsd directly that any tooling can use. We have a old ticket about this. But the apt compiler plugin can detect the @JAXB annotations in the model and extract the javadoc, and generate a json schema with, and then we can load those and enrich into the generated xsd, or enrich into the jaxb model generator, or something. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CAMEL-8000) Container API not usable in WildFly
[ https://issues.apache.org/jira/browse/CAMEL-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-8000: --- Comment: was deleted (was: This blocks the insight-camel integration for Fuse-6.2 on EAP-6.4 https://issues.jboss.org/browse/ENTESB-2173) > Container API not usable in WildFly > --- > > Key: CAMEL-8000 > URL: https://issues.apache.org/jira/browse/CAMEL-8000 > Project: Camel > Issue Type: Bug >Affects Versions: 2.14.0 >Reporter: Thomas Diesler > > There are a number of issues with the Container API that make it unusable in > WildFly > # Concept of unsynchronised singleton > # Call to 3rd party code with partially constructed objects > # Unsynchronised access to a shared resource > Currently there are at least two components that compete for the Container > singleton. The Camel Subsystem and Insight Camel. > I suspect that the Container API cannot be fixed in a compatible way. > Instead the notion of a CamelContextRegistry that fixes the issues with > Container may need to get added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6099) File producer - See if we can support chmod option like ftp producer
[ https://issues.apache.org/jira/browse/CAMEL-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200325#comment-14200325 ] Claus Ibsen commented on CAMEL-6099: I got this unit test error on master Failed tests: FileProducerChmodOptionTest>TestSupport.runBare:58->testInvalidChmod:86 Message was [Failed to create route route4 at: >>> To[file://target/fileProducerChmodOptionTest/?chmod=abc] <<< in route: Route(route4)[[From[direct:writeBadChmod1]] -> [To[file://ta... because of Failed to resolve endpoint: file://target/fileProducerChmodOptionTest/?chmod=abc due to: Could not find a suitable setter for property: chmod as there isn't a setter method with same type: java.lang.String nor type conversion possible: chmod option [abc] is not valid] > File producer - See if we can support chmod option like ftp producer > > > Key: CAMEL-6099 > URL: https://issues.apache.org/jira/browse/CAMEL-6099 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Willem Jiang > Fix For: 2.15.0 > > > See > http://stackoverflow.com/questions/15006065/write-file-with-camel-and-set-chmod > There is some links on that to other SO about how to set chmod using the java > file api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8004) camel-quartz2 - A test may hang
Claus Ibsen created CAMEL-8004: -- Summary: camel-quartz2 - A test may hang Key: CAMEL-8004 URL: https://issues.apache.org/jira/browse/CAMEL-8004 Project: Camel Issue Type: Test Components: tests Reporter: Claus Ibsen Priority: Minor This test seems to hang. I killed the job Running org.apache.camel.component.quartz2.QuartzNameCollisionTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8007) Camel should not be hardcoded to one specific Karaf release
Claus Ibsen created CAMEL-8007:
--
Summary: Camel should not be hardcoded to one specific Karaf
release
Key: CAMEL-8007
URL: https://issues.apache.org/jira/browse/CAMEL-8007
Project: Camel
Issue Type: Bug
Components: karaf
Affects Versions: 2.15.0
Reporter: Claus Ibsen
Priority: Blocker
Fix For: 2.15.0
Something happened so the features.xml now has a hardcoded karaf version
This is from the generated source code:
{code}
http://karaf.apache.org/xmlns/features/v1.0.0";
name='camel-2.15-SNAPSHOT'>
mvn:org.apache.karaf.assemblies.features/spring/2.4.0/xml/features
{code}
Notice how it says karaf 2.4.0.
I suspect it was some spring stuff that was changed. We need to either revert
or find some way for Camel to support Karaf 2.x and 3.x at the same time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7999) Camel Toolbox - Easy information about all Camel components and the release for tooling
[ https://issues.apache.org/jira/browse/CAMEL-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7999: --- Description: A Camel release contains many components, and we have the ability to let components document which options they offer. Though there is currently a few shortcomings that can be improved - the component json schema is currently runtime generated, which requires to load the component and create an instance of it. Instead we should build-time generate it, which we do today with the camel apt compiler plugin. *DONE* - we should include documentation about the option from the javadoc, that allows end users to fully document a component using plain java getter/settr with javadocs, and add those @UriParam annotations for the apt compiler to detect and leverage *DONE* - add a module that embeds all these json schema files in a single module, and also other information, such as the xml schemas, and what else can be handy. Then there is a single module as a one stop shop for tooling and whatnot to gather information about a Camel release. - allow at runtime to explain an endpoint uri what the options in use are, eg as we got the json schema, we can add mbeans that can explain those options, than we can use in tooling, JMX, karaf commands etc. And also IDE editors etc *DONE* - enrich the dsl xml to inject javadoc for the eips into the xml schema, so we have documented in the xsd directly that any tooling can use. We have a old ticket about this. But the apt compiler plugin can detect the @JAXB annotations in the model and extract the javadoc, and generate a json schema with, and then we can load those and enrich into the generated xsd, or enrich into the jaxb model generator, or something. - migrate more Camel components to include javadoc as documentation for their options - figure out how to specify a default value in the json schema. Unfortunately the apt plugin cannot grab that from the source code. So the only solution I can think of now is to add an attribute to the @UriParam where you can specify that, eg this is also what I have seen others do. was: A Camel release contains many components, and we have the ability to let components document which options they offer. Though there is currently a few shortcomings that can be improved - the component json schema is currently runtime generated, which requires to load the component and create an instance of it. Instead we should build-time generate it, which we do today with the camel apt compiler plugin. - we should include documentation about the option from the javadoc, that allows end users to fully document a component using plain java getter/settr with javadocs, and add those @UriParam annotations for the apt compiler to detect and leverage - add a module that embeds all these json schema files in a single module, and also other information, such as the xml schemas, and what else can be handy. Then there is a single module as a one stop shop for tooling and whatnot to gather information about a Camel release. - allow at runtime to explain an endpoint uri what the options in use are, eg as we got the json schema, we can add mbeans that can explain those options, than we can use in tooling, JMX, karaf commands etc. And also IDE editors etc - enrich the dsl xml to inject javadoc for the eips into the xml schema, so we have documented in the xsd directly that any tooling can use. We have a old ticket about this. But the apt compiler plugin can detect the @JAXB annotations in the model and extract the javadoc, and generate a json schema with, and then we can load those and enrich into the generated xsd, or enrich into the jaxb model generator, or something. > Camel Toolbox - Easy information about all Camel components and the release > for tooling > --- > > Key: CAMEL-7999 > URL: https://issues.apache.org/jira/browse/CAMEL-7999 > Project: Camel > Issue Type: New Feature > Components: camel-core, jmx, tooling >Reporter: Claus Ibsen >Assignee: Claus Ibsen > Fix For: 2.15.0 > > > A Camel release contains many components, and we have the ability to let > components document which options they offer. > Though there is currently a few shortcomings that can be improved > - the component json schema is currently runtime generated, which requires to > load the component and create an instance of it. Instead we should build-time > generate it, which we do today with the camel apt compiler plugin. *DONE* > - we should include documentation about the option from the javadoc, that > allows end users to fully document a component using plain java getter/settr > with javadocs, and add those @UriParam annotations for the apt compiler
[jira] [Assigned] (CAMEL-8004) camel-quartz2 - A test may hang
[ https://issues.apache.org/jira/browse/CAMEL-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-8004: -- Assignee: Claus Ibsen > camel-quartz2 - A test may hang > --- > > Key: CAMEL-8004 > URL: https://issues.apache.org/jira/browse/CAMEL-8004 > Project: Camel > Issue Type: Test > Components: tests >Affects Versions: 2.13.3 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.14.1, 2.15.0, 2.13.4 > > Attachments: Screen Shot 2014-11-07 at 10.31.58.png, Screen Shot > 2014-11-07 at 10.32.27.png > > > This test seems to hang. I killed the job > Running org.apache.camel.component.quartz2.QuartzNameCollisionTest -- This message was sent by Atlassian JIRA (v6.3.4#6332)
