[jira] [Updated] (CAMEL-6460) camel-core-http - As a core component for http client and jetty
[ https://issues.apache.org/jira/browse/CAMEL-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-6460: --- Fix Version/s: (was: Future) 3.0.0 camel-core-http - As a core component for http client and jetty --- Key: CAMEL-6460 URL: https://issues.apache.org/jira/browse/CAMEL-6460 Project: Camel Issue Type: Improvement Components: camel-http, camel-jetty Reporter: Claus Ibsen Fix For: 3.0.0 Today camel-jetty and camel-servlet requires camel-http, which has dependency on http client 3.x. We should create a camel-http-core which the shared code, and then let camel-http be the http client component only. And then allow camel-servlet and camel-jetty to dep on camel-http-core and thus not bring in http client 3.1 anymore. See also http://camel.465427.n5.nabble.com/camel-jetty-dependency-on-httpclient-3-tp5734180.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-6460) camel-core-http - As a core component for http client and jetty
[ https://issues.apache.org/jira/browse/CAMEL-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990351#comment-13990351 ] Claus Ibsen commented on CAMEL-6460: We keen 2.x stable as-is, and for 3.0 we can work on this. camel-core-http - As a core component for http client and jetty --- Key: CAMEL-6460 URL: https://issues.apache.org/jira/browse/CAMEL-6460 Project: Camel Issue Type: Improvement Components: camel-http, camel-jetty Reporter: Claus Ibsen Fix For: 3.0.0 Today camel-jetty and camel-servlet requires camel-http, which has dependency on http client 3.x. We should create a camel-http-core which the shared code, and then let camel-http be the http client component only. And then allow camel-servlet and camel-jetty to dep on camel-http-core and thus not bring in http client 3.1 anymore. See also http://camel.465427.n5.nabble.com/camel-jetty-dependency-on-httpclient-3-tp5734180.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7411) EventDrivenPollingConsumer can lose exchanges when the internal queue is full
[
https://issues.apache.org/jira/browse/CAMEL-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7411:
---
Fix Version/s: 2.14.0
2.13.2
EventDrivenPollingConsumer can lose exchanges when the internal queue is full
-
Key: CAMEL-7411
URL: https://issues.apache.org/jira/browse/CAMEL-7411
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.0
Reporter: Benedikt Waldvogel
Priority: Minor
Fix For: 2.13.2, 2.14.0
The exchange processing in the {{EventDrivenPollingConsumer}} can lose
exchanges when the internal queue is bounded and full.
The implementation:
{noformat}
public void process(Exchange exchange) throws Exception {
queue.offer(exchange);
}
{noformat}
The reason is that {{BlockingQueue.offer(...)}} is non-blocking and returns a
boolean which indicates whether the element was added.
However, the return value is ignored causing the exchange to get lost if it
could not be added.
A potential workaround is to use an unbounded BlockingQueue (e.g.
LinkedBlockingQueue).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CAMEL-7411) EventDrivenPollingConsumer can lose exchanges when the internal queue is full
[
https://issues.apache.org/jira/browse/CAMEL-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-7411:
---
Priority: Minor (was: Major)
EventDrivenPollingConsumer can lose exchanges when the internal queue is full
-
Key: CAMEL-7411
URL: https://issues.apache.org/jira/browse/CAMEL-7411
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.0
Reporter: Benedikt Waldvogel
Priority: Minor
The exchange processing in the {{EventDrivenPollingConsumer}} can lose
exchanges when the internal queue is bounded and full.
The implementation:
{noformat}
public void process(Exchange exchange) throws Exception {
queue.offer(exchange);
}
{noformat}
The reason is that {{BlockingQueue.offer(...)}} is non-blocking and returns a
boolean which indicates whether the element was added.
However, the return value is ignored causing the exchange to get lost if it
could not be added.
A potential workaround is to use an unbounded BlockingQueue (e.g.
LinkedBlockingQueue).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7415) lazyLoad with CSV blows up on last line
Willem Jiang created CAMEL-7415:
---
Summary: lazyLoad with CSV blows up on last line
Key: CAMEL-7415
URL: https://issues.apache.org/jira/browse/CAMEL-7415
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.13.0, 2.12.3
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.12.4, 2.13.1
{code}
CsvDataFormat csv = new CsvDataFormat()
csv.setDelimiter(' ')
csv.setSkipFirstLine(false)
csv.setLazyLoad(true)
CamelContext camelContext = new DefaultCamelContext()
camelContext.addRoutes(new RouteBuilder() {
def void configure() {
from('direct:start')
.unmarshal(csv)
.split(body()).streaming()
.log('row: ${body}')
}
})
camelContext.start()
ProducerTemplate t = camelContext.createProducerTemplate()
t.sendBody('direct:start', new File('/Users/timbo/data/test.txt'))
camelContext.stop()
{code}
Here is the exception when camel try to access the last line of the file.
{code}
java.lang.IllegalStateException: java.io.IOException: Stream closed
at
org.apache.camel.dataformat.csv.CsvIterator.next(CsvIterator.java:61)
at
org.apache.camel.processor.Splitter$SplitterIterable$1.next(Splitter.java:170)
at
org.apache.camel.processor.Splitter$SplitterIterable$1.next(Splitter.java:146)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:502)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7415) lazyLoad with CSV blows up on last line
[
https://issues.apache.org/jira/browse/CAMEL-7415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990360#comment-13990360
]
Willem Jiang commented on CAMEL-7415:
-
This issue is caused by the UnmarshalProcessor always wants to close the
inputstream even the marshalled object is iterator.
The input stream can be closed by the iterator, so leave the input stream if
the result object is iterator solve the issue.
lazyLoad with CSV blows up on last line
---
Key: CAMEL-7415
URL: https://issues.apache.org/jira/browse/CAMEL-7415
Project: Camel
Issue Type: Bug
Components: camel-csv
Affects Versions: 2.12.3, 2.13.0
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.12.4, 2.13.1
{code}
CsvDataFormat csv = new CsvDataFormat()
csv.setDelimiter(' ')
csv.setSkipFirstLine(false)
csv.setLazyLoad(true)
CamelContext camelContext = new DefaultCamelContext()
camelContext.addRoutes(new RouteBuilder() {
def void configure() {
from('direct:start')
.unmarshal(csv)
.split(body()).streaming()
.log('row: ${body}')
}
})
camelContext.start()
ProducerTemplate t = camelContext.createProducerTemplate()
t.sendBody('direct:start', new File('/Users/timbo/data/test.txt'))
camelContext.stop()
{code}
Here is the exception when camel try to access the last line of the file.
{code}
java.lang.IllegalStateException: java.io.IOException: Stream closed
at
org.apache.camel.dataformat.csv.CsvIterator.next(CsvIterator.java:61)
at
org.apache.camel.processor.Splitter$SplitterIterable$1.next(Splitter.java:170)
at
org.apache.camel.processor.Splitter$SplitterIterable$1.next(Splitter.java:146)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:502)
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CAMEL-7411) EventDrivenPollingConsumer can lose exchanges when the internal queue is full
[
https://issues.apache.org/jira/browse/CAMEL-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-7411:
--
Assignee: Claus Ibsen
EventDrivenPollingConsumer can lose exchanges when the internal queue is full
-
Key: CAMEL-7411
URL: https://issues.apache.org/jira/browse/CAMEL-7411
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.0
Reporter: Benedikt Waldvogel
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.13.2, 2.14.0
The exchange processing in the {{EventDrivenPollingConsumer}} can lose
exchanges when the internal queue is bounded and full.
The implementation:
{noformat}
public void process(Exchange exchange) throws Exception {
queue.offer(exchange);
}
{noformat}
The reason is that {{BlockingQueue.offer(...)}} is non-blocking and returns a
boolean which indicates whether the element was added.
However, the return value is ignored causing the exchange to get lost if it
could not be added.
A potential workaround is to use an unbounded BlockingQueue (e.g.
LinkedBlockingQueue).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7409) Camel ZipIterator should not eat the IOException
[ https://issues.apache.org/jira/browse/CAMEL-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990384#comment-13990384 ] Willem Jiang commented on CAMEL-7409: - Hi Serge I think just removing the first 2 bytes of the data.zip is not enough, I debugged the code and found out if I did that, camel just cannot read any thing from the zip entry. If I messed up the data.zip file by remove the bytes from multiple place, I can get the same as I test with an empty file stream. Camel ZipIterator should not eat the IOException Key: CAMEL-7409 URL: https://issues.apache.org/jira/browse/CAMEL-7409 Project: Camel Issue Type: Bug Affects Versions: 2.13.0 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.12.4, 2.13.1, 2.14.0 If there are some thing wrong with the Zip file which is split by ZipIterator, we cannot find any warning or exception from the camel route. We should not let ZipIterator eat up the exception without do anything. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CAMEL-7411) EventDrivenPollingConsumer can lose exchanges when the internal queue is full
[
https://issues.apache.org/jira/browse/CAMEL-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7411.
Resolution: Fixed
Thanks for reporting. We now block by default, and there is new options you can
use to configure the initial queue size, and whether to block or not.
Documented at
https://cwiki.apache.org/confluence/display/CAMEL/Polling+Consumer
EventDrivenPollingConsumer can lose exchanges when the internal queue is full
-
Key: CAMEL-7411
URL: https://issues.apache.org/jira/browse/CAMEL-7411
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.13.0
Reporter: Benedikt Waldvogel
Assignee: Claus Ibsen
Priority: Minor
Fix For: 2.13.2, 2.14.0
The exchange processing in the {{EventDrivenPollingConsumer}} can lose
exchanges when the internal queue is bounded and full.
The implementation:
{noformat}
public void process(Exchange exchange) throws Exception {
queue.offer(exchange);
}
{noformat}
The reason is that {{BlockingQueue.offer(...)}} is non-blocking and returns a
boolean which indicates whether the element was added.
However, the return value is ignored causing the exchange to get lost if it
could not be added.
A potential workaround is to use an unbounded BlockingQueue (e.g.
LinkedBlockingQueue).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7416) Improve WS-Security testing
Colm O hEigeartaigh created CAMEL-7416: -- Summary: Improve WS-Security testing Key: CAMEL-7416 URL: https://issues.apache.org/jira/browse/CAMEL-7416 Project: Camel Issue Type: Test Components: camel-cxf Reporter: Colm O hEigeartaigh Fix For: 2.14.0 The WS-Security testing in the camel-cxf component is a bit of a mess and only covers one use-case. Please apply the attached patch, which covers the main use-cases of Signature + Timestamp, Encryption, UsernameToken and WS-SecurityPolicy. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7416) Improve WS-Security testing
[ https://issues.apache.org/jira/browse/CAMEL-7416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CAMEL-7416: --- Attachment: camel-7416.patch Improve WS-Security testing --- Key: CAMEL-7416 URL: https://issues.apache.org/jira/browse/CAMEL-7416 Project: Camel Issue Type: Test Components: camel-cxf Reporter: Colm O hEigeartaigh Fix For: 2.14.0 Attachments: camel-7416.patch The WS-Security testing in the camel-cxf component is a bit of a mess and only covers one use-case. Please apply the attached patch, which covers the main use-cases of Signature + Timestamp, Encryption, UsernameToken and WS-SecurityPolicy. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7417) using .transform(ack()) from camel-hl7 does not work using the spring dsl
Oliver Wilkie created CAMEL-7417: Summary: using .transform(ack()) from camel-hl7 does not work using the spring dsl Key: CAMEL-7417 URL: https://issues.apache.org/jira/browse/CAMEL-7417 Project: Camel Issue Type: Bug Components: camel-hl7 Affects Versions: 2.12.2 Reporter: Oliver Wilkie When the body to return to the mina2:tcp consumer is org.apache.camel.component.hl7.AckExpression we get the error below Caused by: java.lang.IllegalArgumentException: The message to encode is not a supported type: org.apache.camel.component.hl7.AckExpression at org.apache.camel.component.hl7.HL7MLLPEncoder.encode(HL7MLLPEncoder.java:71) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CAMEL-7417) using .transform(ack()) from camel-hl7 does not work using the spring dsl
[ https://issues.apache.org/jira/browse/CAMEL-7417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Wilkie closed CAMEL-7417. Resolution: Invalid using .transform(ack()) from camel-hl7 does not work using the spring dsl - Key: CAMEL-7417 URL: https://issues.apache.org/jira/browse/CAMEL-7417 Project: Camel Issue Type: Bug Components: camel-hl7 Affects Versions: 2.12.2 Reporter: Oliver Wilkie When the body to return to the mina2:tcp consumer is org.apache.camel.component.hl7.AckExpression we get the error below Caused by: java.lang.IllegalArgumentException: The message to encode is not a supported type: org.apache.camel.component.hl7.AckExpression at org.apache.camel.component.hl7.HL7MLLPEncoder.encode(HL7MLLPEncoder.java:71) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CAMEL-7412) [docs] The docs state camel-jdbc does not support transactions.
[
https://issues.apache.org/jira/browse/CAMEL-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990719#comment-13990719
]
Torsten Mielke commented on CAMEL-7412:
---
I am going to remove the statement for now. Please let me know if this raises
any concerns.
Again, have tested the camel-jdbc component (2.12.0) with XA transactions
myself and am confident that it works correctly.
[docs] The docs state camel-jdbc does not support transactions.
---
Key: CAMEL-7412
URL: https://issues.apache.org/jira/browse/CAMEL-7412
Project: Camel
Issue Type: Bug
Components: camel-jdbc
Affects Versions: 2.12.3
Reporter: Torsten Mielke
Priority: Minor
The docs at http://camel.apache.org/jdbc.html state
{quote}
This component can not be used as a Transactional Client. If you need
transaction support in your route, you should use the SQL component instead.
{quote}
This statement however seems to be wrong.
I have a demo at
https://github.com/tmielke/fuse-demos/tree/master/Camel/Camel-JMS-JDBC-XA-TX
that uses the camel-jdbc component in an XA transaction scenario without
errors.
Can someone please confirm the docs is wrong and I can correct it in the
docs?
This statement was introduced in
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27822683
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CAMEL-7412) [docs] The docs state camel-jdbc does not support transactions.
[
https://issues.apache.org/jira/browse/CAMEL-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torsten Mielke resolved CAMEL-7412.
---
Resolution: Fixed
Fix Version/s: 2.13.0
Fixed in revision 31 of
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=64933
[docs] The docs state camel-jdbc does not support transactions.
---
Key: CAMEL-7412
URL: https://issues.apache.org/jira/browse/CAMEL-7412
Project: Camel
Issue Type: Bug
Components: camel-jdbc
Affects Versions: 2.12.3
Reporter: Torsten Mielke
Priority: Minor
Fix For: 2.13.0
The docs at http://camel.apache.org/jdbc.html state
{quote}
This component can not be used as a Transactional Client. If you need
transaction support in your route, you should use the SQL component instead.
{quote}
This statement however seems to be wrong.
I have a demo at
https://github.com/tmielke/fuse-demos/tree/master/Camel/Camel-JMS-JDBC-XA-TX
that uses the camel-jdbc component in an XA transaction scenario without
errors.
Can someone please confirm the docs is wrong and I can correct it in the
docs?
This statement was introduced in
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27822683
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CAMEL-7409) Camel ZipIterator should not eat the IOException
[
https://issues.apache.org/jira/browse/CAMEL-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990746#comment-13990746
]
Serge Shikov commented on CAMEL-7409:
-
Yes, probably ZipInputStream just can't read anything, but ZipFile could detect
such corrupted zips.
What about something like in ZipIterator constructor?
{code}
try {
final ZipFile zipFile= new
ZipFile(inputMessage.getBody(File.class));
final InputStream inputStream =
inputMessage.getBody(InputStream.class);
if (inputStream instanceof ZipInputStream) {
zipInputStream = (ZipInputStream)inputStream;
} else {
zipInputStream = new ZipInputStream(new
BufferedInputStream(inputStream));
}
} catch (ZipException e) {
LOGGER.error(ZipException, e);
zipInputStream= null;
// orthrow new RuntimeException(ZipException, e);
} catch (IOException e) {
LOGGER.error(IOException, e);
zipInputStream= null;
// or throw new RuntimeException(IOException, e);
}
{code}
Camel ZipIterator should not eat the IOException
Key: CAMEL-7409
URL: https://issues.apache.org/jira/browse/CAMEL-7409
Project: Camel
Issue Type: Bug
Affects Versions: 2.13.0
Reporter: Willem Jiang
Assignee: Willem Jiang
Fix For: 2.12.4, 2.13.1, 2.14.0
If there are some thing wrong with the Zip file which is split by
ZipIterator, we cannot find any warning or exception from the camel route. We
should not let ZipIterator eat up the exception without do anything.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CAMEL-7418) org.apache.camel.impl.JndiRegistry.findByTypeWithName
André Ricardo da Silva Souza created CAMEL-7418: --- Summary: org.apache.camel.impl.JndiRegistry.findByTypeWithName Key: CAMEL-7418 URL: https://issues.apache.org/jira/browse/CAMEL-7418 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.0 Reporter: André Ricardo da Silva Souza I guess this line isn't correct: if (type.isInstance(pair.getClass()) || type.getName().equals(pair.getClassName())) The variable pair.getClass() always returns javax.naming.NameClassPair or its subclasses and the method isInstance works only with Instances, but doesnt Classes. I think the correct code should be: if (type.isAssignableFrom(Class.forName(pair.getClassName( || type.getName().equals(pair.getClassName())) I've tried to test a transacted route, but i couldnt because the error: Failed to create route route1 at: Transacted[] in route: Route(route1)[[From[direct:start]] - [Transacted[]]] because of No bean could be found in the registry of type: PlatformTransactionManager -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7418) org.apache.camel.impl.JndiRegistry.findByTypeWithName
[ https://issues.apache.org/jira/browse/CAMEL-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] André Ricardo da Silva Souza updated CAMEL-7418: Description: I guess this line isn't correct: if (type.isInstance(pair.getClass()) || type.getName().equals(pair.getClassName())) The variable pair.getClass() always returns javax.naming.NameClassPair or its subclasses and the method isInstance works only with Instances, but doesnt Classes. I think the correct code should be: if (type.isAssignableFrom(Class.forName(pair.getClassName( I've tried to test a transacted route, but i couldnt because the error: Failed to create route route1 at: Transacted[] in route: Route(route1)[[From[direct:start]] - [Transacted[]]] because of No bean could be found in the registry of type: PlatformTransactionManager was: I guess this line isn't correct: if (type.isInstance(pair.getClass()) || type.getName().equals(pair.getClassName())) The variable pair.getClass() always returns javax.naming.NameClassPair or its subclasses and the method isInstance works only with Instances, but doesnt Classes. I think the correct code should be: if (type.isAssignableFrom(Class.forName(pair.getClassName( || type.getName().equals(pair.getClassName())) I've tried to test a transacted route, but i couldnt because the error: Failed to create route route1 at: Transacted[] in route: Route(route1)[[From[direct:start]] - [Transacted[]]] because of No bean could be found in the registry of type: PlatformTransactionManager org.apache.camel.impl.JndiRegistry.findByTypeWithName - Key: CAMEL-7418 URL: https://issues.apache.org/jira/browse/CAMEL-7418 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.0 Reporter: André Ricardo da Silva Souza I guess this line isn't correct: if (type.isInstance(pair.getClass()) || type.getName().equals(pair.getClassName())) The variable pair.getClass() always returns javax.naming.NameClassPair or its subclasses and the method isInstance works only with Instances, but doesnt Classes. I think the correct code should be: if (type.isAssignableFrom(Class.forName(pair.getClassName( I've tried to test a transacted route, but i couldnt because the error: Failed to create route route1 at: Transacted[] in route: Route(route1)[[From[direct:start]] - [Transacted[]]] because of No bean could be found in the registry of type: PlatformTransactionManager -- This message was sent by Atlassian JIRA (v6.2#6252)
