[jira] [Commented] (CAMEL-11999) Cannot create queue/message for Azure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247120#comment-16247120
 ] 

ASF GitHub Bot commented on CAMEL-11999:


davsclaus commented on issue #2087: [CAMEL-11999] Cannot create queue/message 
for Azure
URL: https://github.com/apache/camel/pull/2087#issuecomment-343396880
 
 
   Also seems like you need to fix checkstyle


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Cannot create queue/message for Azure
> -
>
> Key: CAMEL-11999
> URL: https://issues.apache.org/jira/browse/CAMEL-11999
> Project: Camel
>  Issue Type: Bug
>  Components: camel-azure
>Affects Versions: 2.20.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
> Fix For: 2.20.1
>
>
> The Azure Storage Queue API may have changed unnoticed since the component 
> was incepted. 
> Currently it is broken in multiple places.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1819



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11999) Cannot create queue/message for Azure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247117#comment-16247117
 ] 

ASF GitHub Bot commented on CAMEL-11999:


davsclaus commented on issue #2087: [CAMEL-11999] Cannot create queue/message 
for Azure
URL: https://github.com/apache/camel/pull/2087#issuecomment-343395613
 
 
   @onders86 +1 to backport


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Cannot create queue/message for Azure
> -
>
> Key: CAMEL-11999
> URL: https://issues.apache.org/jira/browse/CAMEL-11999
> Project: Camel
>  Issue Type: Bug
>  Components: camel-azure
>Affects Versions: 2.20.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
> Fix For: 2.20.1
>
>
> The Azure Storage Queue API may have changed unnoticed since the component 
> was incepted. 
> Currently it is broken in multiple places.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1819



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11999) Cannot create queue/message for Azure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247107#comment-16247107
 ] 

ASF GitHub Bot commented on CAMEL-11999:


oscerd commented on issue #2087: [CAMEL-11999] Cannot create queue/message for 
Azure
URL: https://github.com/apache/camel/pull/2087#issuecomment-343392201
 
 
   @davsclaus can we pull this one in 2.20.x before the 2.20.1 cut or do we 
have to wait?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Cannot create queue/message for Azure
> -
>
> Key: CAMEL-11999
> URL: https://issues.apache.org/jira/browse/CAMEL-11999
> Project: Camel
>  Issue Type: Bug
>  Components: camel-azure
>Affects Versions: 2.20.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
> Fix For: 2.20.1
>
>
> The Azure Storage Queue API may have changed unnoticed since the component 
> was incepted. 
> Currently it is broken in multiple places.
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1819



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-12001) Cannot create a component based on the SqlComponent

[Luca Burgazzoli (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16247050#comment-16247050
 ] 

Luca Burgazzoli commented on CAMEL-12001:
-

[~gzurowski] any chance to recut 2.20.1 so it includes this one ?

> Cannot create a component based on the SqlComponent
> ---
>
> Key: CAMEL-12001
> URL: https://issues.apache.org/jira/browse/CAMEL-12001
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.20.0
> Environment: any
>Reporter: Kurt T Stam
>Assignee: Luca Burgazzoli
> Fix For: 2.20.2, 2.21.0
>
>
> I created a the following component
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/main/java/io/syndesis/connector/sql/SqlConnectorComponent.java
> and this route just never gets executed
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/test/java/io/syndesis/connector/sql/SqlConnectorComponentTest.java#L107
> And not any of the getBefore/AfterProducer methods are called either, which I 
> think had to do with the fact that the SqlComponent is not a DefaultComponent.
> I tried with v2.20.0 as well as v2.21.0-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Work started] (CAMEL-12001) Cannot create a component based on the SqlComponent

[Luca Burgazzoli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on CAMEL-12001 started by Luca Burgazzoli.
---
> Cannot create a component based on the SqlComponent
> ---
>
> Key: CAMEL-12001
> URL: https://issues.apache.org/jira/browse/CAMEL-12001
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.20.0
> Environment: any
>Reporter: Kurt T Stam
>Assignee: Luca Burgazzoli
> Fix For: 2.20.2, 2.21.0
>
>
> I created a the following component
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/main/java/io/syndesis/connector/sql/SqlConnectorComponent.java
> and this route just never gets executed
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/test/java/io/syndesis/connector/sql/SqlConnectorComponentTest.java#L107
> And not any of the getBefore/AfterProducer methods are called either, which I 
> think had to do with the fact that the SqlComponent is not a DefaultComponent.
> I tried with v2.20.0 as well as v2.21.0-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-12001) Cannot create a component based on the SqlComponent

[Luca Burgazzoli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luca Burgazzoli updated CAMEL-12001:

Fix Version/s: 2.21.0
   2.20.2

> Cannot create a component based on the SqlComponent
> ---
>
> Key: CAMEL-12001
> URL: https://issues.apache.org/jira/browse/CAMEL-12001
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.20.0
> Environment: any
>Reporter: Kurt T Stam
>Assignee: Luca Burgazzoli
> Fix For: 2.20.2, 2.21.0
>
>
> I created a the following component
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/main/java/io/syndesis/connector/sql/SqlConnectorComponent.java
> and this route just never gets executed
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/test/java/io/syndesis/connector/sql/SqlConnectorComponentTest.java#L107
> And not any of the getBefore/AfterProducer methods are called either, which I 
> think had to do with the fact that the SqlComponent is not a DefaultComponent.
> I tried with v2.20.0 as well as v2.21.0-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (CAMEL-12001) Cannot create a component based on the SqlComponent

[Luca Burgazzoli (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-12001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luca Burgazzoli reassigned CAMEL-12001:
---

Assignee: Luca Burgazzoli

> Cannot create a component based on the SqlComponent
> ---
>
> Key: CAMEL-12001
> URL: https://issues.apache.org/jira/browse/CAMEL-12001
> Project: Camel
>  Issue Type: Bug
>  Components: camel-sql
>Affects Versions: 2.20.0
> Environment: any
>Reporter: Kurt T Stam
>Assignee: Luca Burgazzoli
>
> I created a the following component
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/main/java/io/syndesis/connector/sql/SqlConnectorComponent.java
> and this route just never gets executed
> https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/test/java/io/syndesis/connector/sql/SqlConnectorComponentTest.java#L107
> And not any of the getBefore/AfterProducer methods are called either, which I 
> think had to do with the fact that the SqlComponent is not a DefaultComponent.
> I tried with v2.20.0 as well as v2.21.0-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CAMEL-12001) Cannot create a component based on the SqlComponent

[Kurt T Stam (JIRA)]

Kurt T Stam created CAMEL-12001:
---

 Summary: Cannot create a component based on the SqlComponent
 Key: CAMEL-12001
 URL: https://issues.apache.org/jira/browse/CAMEL-12001
 Project: Camel
  Issue Type: Bug
  Components: camel-sql
Affects Versions: 2.20.0
 Environment: any
Reporter: Kurt T Stam


I created a the following component

https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/main/java/io/syndesis/connector/sql/SqlConnectorComponent.java

and this route just never gets executed

https://github.com/KurtStam/connectors/blob/sql-connector/connectors/sql/sql-connector/src/test/java/io/syndesis/connector/sql/SqlConnectorComponentTest.java#L107

And not any of the getBefore/AfterProducer methods are called either, which I 
think had to do with the fact that the SqlComponent is not a DefaultComponent.

I tried with v2.20.0 as well as v2.21.0-SNAPSHOT



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11954) Camel JMX name for cluster service

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245945#comment-16245945
 ] 

ASF GitHub Bot commented on CAMEL-11954:


vrlgohel opened a new pull request #2088: CAMEL-11954: Renamed ha packages to 
cluster
URL: https://github.com/apache/camel/pull/2088
 
 
   Issue: https://issues.apache.org/jira/browse/CAMEL-11954
   
   Refactored the code to have 'cluster' instead of 'ha' packages. The 
components, spring-boot starters, camel examples, and the tests work fine. 
   The branch is state is also fine :+1: 
   
   Guys, can you let me know if any more changes are needed ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Camel JMX name for cluster service
> --
>
> Key: CAMEL-11954
> URL: https://issues.apache.org/jira/browse/CAMEL-11954
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, jmx
>Reporter: Claus Ibsen
>Assignee: Viral Gohel
> Fix For: 2.21.0
>
> Attachments: CAMEL11954-Renamed-HA-packages-to-cluster.patch
>
>
> We use ha today, which is a bit too short and confusing.
> Lets rename this to something better, like cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11954) Camel JMX name for cluster service

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245946#comment-16245946
 ] 

ASF GitHub Bot commented on CAMEL-11954:


GitHub user vrlgohel opened a pull request:

https://github.com/apache/camel/pull/2088

CAMEL-11954: Renamed ha packages to cluster

Issue: https://issues.apache.org/jira/browse/CAMEL-11954

Refactored the code to have 'cluster' instead of 'ha' packages. The 
components, spring-boot starters, camel examples, and the tests work fine. 
The branch is state is also fine :+1: 

Guys, can you let me know if any more changes are needed ?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vrlgohel/camel-1 CAMEL-11954

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2088.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2088


commit 3b22c5fcc0b51b5c7a244b4aa94db8d19a39b8a6
Author: Viral Gohel 
Date:   2017-11-09T16:17:18Z

CAMEL-11954: Renamed ha packages to cluster




> Camel JMX name for cluster service
> --
>
> Key: CAMEL-11954
> URL: https://issues.apache.org/jira/browse/CAMEL-11954
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, jmx
>Reporter: Claus Ibsen
>Assignee: Viral Gohel
> Fix For: 2.21.0
>
> Attachments: CAMEL11954-Renamed-HA-packages-to-cluster.patch
>
>
> We use ha today, which is a bit too short and confusing.
> Lets rename this to something better, like cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11656) Support default directory sorter for FileConsumer

[Viktor Khoroshko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245700#comment-16245700
 ] 

Viktor Khoroshko edited comment on CAMEL-11656 at 11/9/17 2:05 PM:
---

Just sort list of files found alphabetically by default in the code placeholder 
"// sort there" from above description.


was (Author: oceansize):
Just sort list of files of found alphabetically by default in the code 
placeholder "// sort there" from above description.

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>Priority: Minor
> Fix For: Future
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11656) Support default directory sorter for FileConsumer

[Viktor Khoroshko (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245700#comment-16245700
 ] 

Viktor Khoroshko commented on CAMEL-11656:
--

Just sort list of files of found alphabetically by default in the code 
placeholder "// sort there" from above description.

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>Priority: Minor
> Fix For: Future
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245573#comment-16245573
 ] 

Robert Half edited comment on CAMEL-11846 at 11/9/17 12:38 PM:
---

!my  example looks like this (and  it's really UTF-16BE).png!

it cannot be parsed by Camel out of the box, because it would tell 
XmlStreamReader, it needs to use UTF-8 as encoding, so it will fail at first 
bytes, which are BOM


was (Author: antidote2):
!my  example looks like this (and  it's really UTF-16BE).png!

> xtokenize and apply xslt to a string does not work  with UTF-16BE
> -
>
> Key: CAMEL-11846
> URL: https://issues.apache.org/jira/browse/CAMEL-11846
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.5
>Reporter: Robert Half
> Attachments: UTF-16BE (with BOM).png, my  example looks like this 
> (and  it's really UTF-16BE).png
>
>
> In XML, encoding is often provided inside  tag. In general, you 
> cannot read the tag, if you don't know the encoding, but XML Parsers support 
> the detection of several encodings which allows them to read the tag. With 
> that information they can read the whole file without knowing the "charset" 
> in first place.
> xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by 
> providing a reader Camel tells, that it knows the encoding, so it won't be 
> detected by the XML parser.
> Also Camel sets the charset to UTF-8 if it is not provided inside a header. 
> This makes the underlying reader fail reading UTF-16.
> Using XmlInputFactory#createXmlStreamReader(InputStream) inside 
> XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps 
> fails again because it again uses a Reader.
> See Stackoverflow Question for reference:
> [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Half updated CAMEL-11846:

Attachment: my  example looks like this (and  it's really UTF-16BE).png

> xtokenize and apply xslt to a string does not work  with UTF-16BE
> -
>
> Key: CAMEL-11846
> URL: https://issues.apache.org/jira/browse/CAMEL-11846
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.5
>Reporter: Robert Half
> Attachments: UTF-16BE (with BOM).png, my  example looks like this 
> (and  it's really UTF-16BE).png
>
>
> In XML, encoding is often provided inside  tag. In general, you 
> cannot read the tag, if you don't know the encoding, but XML Parsers support 
> the detection of several encodings which allows them to read the tag. With 
> that information they can read the whole file without knowing the "charset" 
> in first place.
> xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by 
> providing a reader Camel tells, that it knows the encoding, so it won't be 
> detected by the XML parser.
> Also Camel sets the charset to UTF-8 if it is not provided inside a header. 
> This makes the underlying reader fail reading UTF-16.
> Using XmlInputFactory#createXmlStreamReader(InputStream) inside 
> XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps 
> fails again because it again uses a Reader.
> See Stackoverflow Question for reference:
> [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245564#comment-16245564
 ] 

Robert Half edited comment on CAMEL-11846 at 11/9/17 12:36 PM:
---

!UTF-16BE (with BOM).png!

Hmmm I am not able  to attach xml file here...

I think you can easily create a  test file by converting any UTF-8 XML to 
UTF-16BE with notepad++ for example.



was (Author: antidote2):
!UTF-16BE (with BOM).png!

Hmmm I am not able  to attach xml file here...



> xtokenize and apply xslt to a string does not work  with UTF-16BE
> -
>
> Key: CAMEL-11846
> URL: https://issues.apache.org/jira/browse/CAMEL-11846
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.5
>Reporter: Robert Half
> Attachments: UTF-16BE (with BOM).png
>
>
> In XML, encoding is often provided inside  tag. In general, you 
> cannot read the tag, if you don't know the encoding, but XML Parsers support 
> the detection of several encodings which allows them to read the tag. With 
> that information they can read the whole file without knowing the "charset" 
> in first place.
> xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by 
> providing a reader Camel tells, that it knows the encoding, so it won't be 
> detected by the XML parser.
> Also Camel sets the charset to UTF-8 if it is not provided inside a header. 
> This makes the underlying reader fail reading UTF-16.
> Using XmlInputFactory#createXmlStreamReader(InputStream) inside 
> XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps 
> fails again because it again uses a Reader.
> See Stackoverflow Question for reference:
> [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245564#comment-16245564
 ] 

Robert Half edited comment on CAMEL-11846 at 11/9/17 12:35 PM:
---

!UTF-16BE (with BOM).png!

Hmmm I am not able  to attach xml file here...




was (Author: antidote2):
!UTF-16BE (with BOM).png!

Hmmm I am not able  to attach xml file here

> xtokenize and apply xslt to a string does not work  with UTF-16BE
> -
>
> Key: CAMEL-11846
> URL: https://issues.apache.org/jira/browse/CAMEL-11846
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.5
>Reporter: Robert Half
> Attachments: UTF-16BE (with BOM).png
>
>
> In XML, encoding is often provided inside  tag. In general, you 
> cannot read the tag, if you don't know the encoding, but XML Parsers support 
> the detection of several encodings which allows them to read the tag. With 
> that information they can read the whole file without knowing the "charset" 
> in first place.
> xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by 
> providing a reader Camel tells, that it knows the encoding, so it won't be 
> detected by the XML parser.
> Also Camel sets the charset to UTF-8 if it is not provided inside a header. 
> This makes the underlying reader fail reading UTF-16.
> Using XmlInputFactory#createXmlStreamReader(InputStream) inside 
> XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps 
> fails again because it again uses a Reader.
> See Stackoverflow Question for reference:
> [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Half updated CAMEL-11846:

Attachment: UTF-16BE (with BOM).png

> xtokenize and apply xslt to a string does not work  with UTF-16BE
> -
>
> Key: CAMEL-11846
> URL: https://issues.apache.org/jira/browse/CAMEL-11846
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.5
>Reporter: Robert Half
> Attachments: UTF-16BE (with BOM).png
>
>
> In XML, encoding is often provided inside  tag. In general, you 
> cannot read the tag, if you don't know the encoding, but XML Parsers support 
> the detection of several encodings which allows them to read the tag. With 
> that information they can read the whole file without knowing the "charset" 
> in first place.
> xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by 
> providing a reader Camel tells, that it knows the encoding, so it won't be 
> detected by the XML parser.
> Also Camel sets the charset to UTF-8 if it is not provided inside a header. 
> This makes the underlying reader fail reading UTF-16.
> Using XmlInputFactory#createXmlStreamReader(InputStream) inside 
> XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps 
> fails again because it again uses a Reader.
> See Stackoverflow Question for reference:
> [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1624#comment-1624
 ] 

Robert Half edited comment on CAMEL-11846 at 11/9/17 12:23 PM:
---

Hi Viral,

I have a workaround first: I use BufferedInputStream wrapper, so I am able to 
reset it later (don't need to open the file twice). I give the InputStream  to 
XmlStreamReader, which gives me the encoding after reading XML file prolog. 
Then I set it for camel on the Exchange.CHARSET_NAME header:


{code:java}
EncodingUtil.DetectedEncodingStream detectedEncodingStream = 
EncodingUtil.detectEncoding(inputStream, new StaxConverter().getInputFactory());
inputStream = detectedEncodingStream.inputStream;
exchange.getIn().setHeader(Exchange.CHARSET_NAME, 
detectedEncodingStream.encoding);
{code}


{code:java}
public class EncodingUtil {

public static class DetectedEncodingStream {
public InputStream inputStream;
public String encoding;

public DetectedEncodingStream(InputStream inputStream, String encoding) 
{
this.inputStream = inputStream;
this.encoding = encoding;
}
}

private static final int MAX_REWINDABLE_STREAM_BUFFER = 2*4196;

public static final Logger LOGGER = 
LoggerFactory.getLogger(EncodingUtil.class);

public static DetectedEncodingStream detectEncoding(InputStream 
inputStream, XMLInputFactory xmlInputFactory) {
final BufferedInputStream bufferedInputStream = new 
BufferedInputStream(inputStream, MAX_REWINDABLE_STREAM_BUFFER);
bufferedInputStream.mark(MAX_REWINDABLE_STREAM_BUFFER);
String encoding;
XMLStreamReader xmlStreamReader = null;
try {
xmlStreamReader = 
xmlInputFactory.createXMLStreamReader(bufferedInputStream);
} catch (XMLStreamException e) {
throw new RuntimeException(e);
} finally {
try {
bufferedInputStream.reset();
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
try {
xmlStreamReader.close();
} catch (XMLStreamException e) {
throw new RuntimeException("Failed to close 
XmlStreamRader", e);
}
}
}

encoding = xmlStreamReader.getCharacterEncodingScheme();
if (encoding == null) {
encoding = StandardCharsets.UTF_8.name();
}
return new DetectedEncodingStream(bufferedInputStream, encoding);
}
}
{code}



was (Author: antidote2):
Hi Viral,

I have a workaround first: I use BufferedInputStream wrapper, so I am able to 
reset it later (don't need to open the file twice). I give the InputStream  to 
XmlStreamReader, which gives me the encoding after reading XML file prolog. 
Then I set it for camel on the Exchange.CHARSET_NAME header:

EncodingUtil.DetectedEncodingStream detectedEncodingStream = 
EncodingUtil.detectEncoding(inputStream, new StaxConverter().getInputFactory());
inputStream = detectedEncodingStream.inputStream;
exchange.getIn().setHeader(Exchange.CHARSET_NAME, 
detectedEncodingStream.encoding);

{code:java}
public class EncodingUtil {

public static class DetectedEncodingStream {
public InputStream inputStream;
public String encoding;

public DetectedEncodingStream(InputStream inputStream, String encoding) 
{
this.inputStream = inputStream;
this.encoding = encoding;
}
}

private static final int MAX_REWINDABLE_STREAM_BUFFER = 2*4196;

public static final Logger LOGGER = 
LoggerFactory.getLogger(EncodingUtil.class);

public static DetectedEncodingStream detectEncoding(InputStream 
inputStream, XMLInputFactory xmlInputFactory) {
final BufferedInputStream bufferedInputStream = new 
BufferedInputStream(inputStream, MAX_REWINDABLE_STREAM_BUFFER);
bufferedInputStream.mark(MAX_REWINDABLE_STREAM_BUFFER);
String encoding;
XMLStreamReader xmlStreamReader = null;
try {
xmlStreamReader = 
xmlInputFactory.createXMLStreamReader(bufferedInputStream);
} catch (XMLStreamException e) {
throw new RuntimeException(e);
} finally {
try {
bufferedInputStream.reset();
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
try {
xmlStreamReader.close();
} catch (XMLStreamException e) {
throw new RuntimeException("Failed to close 
XmlStreamRader", e);
}
}
}

encoding = xmlStreamReader.getCharacterEncodingScheme();
if (encoding == null) {
encoding = StandardCharsets.UTF_8.name();
}
return 

[jira] [Commented] (CAMEL-11846) xtokenize and apply xslt to a string does not work with UTF-16BE

[Robert Half (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1624#comment-1624
 ] 

Robert Half commented on CAMEL-11846:
-

Hi Viral,

I have a workaround first: I use BufferedInputStream wrapper, so I am able to 
reset it later (don't need to open the file twice). I give the InputStream  to 
XmlStreamReader, which gives me the encoding after reading XML file prolog. 
Then I set it for camel on the Exchange.CHARSET_NAME header:

EncodingUtil.DetectedEncodingStream detectedEncodingStream = 
EncodingUtil.detectEncoding(inputStream, new StaxConverter().getInputFactory());
inputStream = detectedEncodingStream.inputStream;
exchange.getIn().setHeader(Exchange.CHARSET_NAME, 
detectedEncodingStream.encoding);

{code:java}
public class EncodingUtil {

public static class DetectedEncodingStream {
public InputStream inputStream;
public String encoding;

public DetectedEncodingStream(InputStream inputStream, String encoding) 
{
this.inputStream = inputStream;
this.encoding = encoding;
}
}

private static final int MAX_REWINDABLE_STREAM_BUFFER = 2*4196;

public static final Logger LOGGER = 
LoggerFactory.getLogger(EncodingUtil.class);

public static DetectedEncodingStream detectEncoding(InputStream 
inputStream, XMLInputFactory xmlInputFactory) {
final BufferedInputStream bufferedInputStream = new 
BufferedInputStream(inputStream, MAX_REWINDABLE_STREAM_BUFFER);
bufferedInputStream.mark(MAX_REWINDABLE_STREAM_BUFFER);
String encoding;
XMLStreamReader xmlStreamReader = null;
try {
xmlStreamReader = 
xmlInputFactory.createXMLStreamReader(bufferedInputStream);
} catch (XMLStreamException e) {
throw new RuntimeException(e);
} finally {
try {
bufferedInputStream.reset();
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
try {
xmlStreamReader.close();
} catch (XMLStreamException e) {
throw new RuntimeException("Failed to close 
XmlStreamRader", e);
}
}
}

encoding = xmlStreamReader.getCharacterEncodingScheme();
if (encoding == null) {
encoding = StandardCharsets.UTF_8.name();
}
return new DetectedEncodingStream(bufferedInputStream, encoding);
}
}
{code}


> xtokenize and apply xslt to a string does not work  with UTF-16BE
> -
>
> Key: CAMEL-11846
> URL: https://issues.apache.org/jira/browse/CAMEL-11846
> Project: Camel
>  Issue Type: Bug
>  Components: camel-core
>Affects Versions: 2.17.5
>Reporter: Robert Half
>
> In XML, encoding is often provided inside  tag. In general, you 
> cannot read the tag, if you don't know the encoding, but XML Parsers support 
> the detection of several encodings which allows them to read the tag. With 
> that information they can read the whole file without knowing the "charset" 
> in first place.
> xtokenize and xslt use XmlInputFactory#createXmlStreamReader(Reader). But by 
> providing a reader Camel tells, that it knows the encoding, so it won't be 
> detected by the XML parser.
> Also Camel sets the charset to UTF-8 if it is not provided inside a header. 
> This makes the underlying reader fail reading UTF-16.
> Using XmlInputFactory#createXmlStreamReader(InputStream) inside 
> XMLTokenExpressionIterator works (tried in a patch). But the next xslt steps 
> fails again because it again uses a Reader.
> See Stackoverflow Question for reference:
> [https://stackoverflow.com/questions/46322376/apache-camel-to-handle-encoding-declared-in-xml-file]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11954) Camel JMX name for cluster service

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245472#comment-16245472
 ] 

ASF GitHub Bot commented on CAMEL-11954:


Github user vrlgohel closed the pull request at:

https://github.com/apache/camel/pull/2086


> Camel JMX name for cluster service
> --
>
> Key: CAMEL-11954
> URL: https://issues.apache.org/jira/browse/CAMEL-11954
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core, jmx
>Reporter: Claus Ibsen
>Assignee: Viral Gohel
> Fix For: 2.21.0
>
> Attachments: CAMEL11954-Renamed-HA-packages-to-cluster.patch
>
>
> We use ha today, which is a bit too short and confusing.
> Lets rename this to something better, like cluster.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11987) Camel-SalesForce DTO Issue while using camel-salesforce-maven

[Zoran Regvart (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245453#comment-16245453
 ] 

Zoran Regvart commented on CAMEL-11987:
---

[~srinivasks22] you seem to be using version {{2.20.0.fuse-000120-redhat-1}} 
this is not something we can support at the Apache, you need to contact RedHat 
support for that. This was fixed in version 2.21 that you can use by running 
{{mvn 
org.apache.camel.maven:camel-salesforce-maven-plugin:2.21.0-SNAPSHOT:generate 
...}}.

> Camel-SalesForce DTO Issue while using camel-salesforce-maven
> -
>
> Key: CAMEL-11987
> URL: https://issues.apache.org/jira/browse/CAMEL-11987
> Project: Camel
>  Issue Type: Bug
>  Components: camel-salesforce
>Affects Versions: 2.17.7, 2.20.0
>Reporter: srinivas
>Assignee: Zoran Regvart
>Priority: Blocker
> Fix For: 2.21.0
>
>
> I'm trying to connect to our private salesforce cloud using camel and trying 
> to generate DTO's using the camel-salesforce-maven. It connects well and it 
> shows that there are about 627 objects found. Then while trying to generate 
> the java classes it throws the exception as below. I'm using the below 
> command and I've tried with the 2.18. 2.19 and 2.20 versions but I see this 
> consistent error across all the versions. 
> mvn camel-salesforce:generate -DcamelSalesforce.clientId= 
> -DcamelSalesforce.clientSecret=-DcamelSalesforce.userName= 
> -DcamelSalesforce.password= -DcamelSalesforce.loginUrl= 
> -DcamelSalesforce.version=41.0
> [INFO] Scanning for projects...
> [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is missing, 
> no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin 
> org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies could not 
> be resolved: Failure to find org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 in 
> https://maven.repository.redhat.com/techpreview/all/ was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> redhat-techpreview-all-repository has elapsed or updates are forced
> [WARNING] The POM for 
> org.apache.maven.plugins:maven-surefire-plugin:jar:{maven-surefire-plugin-version}
>  is missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.apache.maven.plugins:maven-surefire-plugin:{maven-surefire-plugin-version}:
>  Plugin 
> org.apache.maven.plugins:maven-surefire-plugin:{maven-surefire-plugin-version}
>  or one of its dependencies could not be resolved: Failure to find 
> org.apache.maven.plugins:maven-surefire-plugin:jar:{maven-surefire-plugin-version}
>  in https://maven.repository.redhat.com/techpreview/all/ was cached in the 
> local repository, resolution will not be reattempted until the update 
> interval of redhat-techpreview-all-repository has elapsed or updates are 
> forced
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building Camel :: Salesforce :: Maven plugin 2.17.8-SNAPSHOT
> [INFO] 
> 
> [WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is missing, 
> no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin 
> org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies could not 
> be resolved: Failure to find org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 in 
> https://maven.repository.redhat.com/techpreview/all/ was cached in the local 
> repository, resolution will not be reattempted until the update interval of 
> redhat-techpreview-all-repository has elapsed or updates are forced
> [WARNING] The POM for 
> org.apache.maven.plugins:maven-surefire-plugin:jar:{maven-surefire-plugin-version}
>  is missing, no dependency information available
> [WARNING] Failed to retrieve plugin descriptor for 
> org.apache.maven.plugins:maven-surefire-plugin:{maven-surefire-plugin-version}:
>  Plugin 
> org.apache.maven.plugins:maven-surefire-plugin:{maven-surefire-plugin-version}
>  or one of its dependencies could not be resolved: Failure to find 
> org.apache.maven.plugins:maven-surefire-plugin:jar:{maven-surefire-plugin-version}
>  in https://maven.repository.redhat.com/techpreview/all/ was cached in the 
> local repository, resolution will not be reattempted until the update 
> interval of redhat-techpreview-all-repository has elapsed or updates are 
> forced
> [INFO] 
> [INFO] --- camel-salesforce-maven-plugin:2.18.1.redhat-21:generate 
> (default-cli) @ 

[jira] [Commented] (CAMEL-11174) REST-DSL support for Google Protobuf

[Luis (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245447#comment-16245447
 ] 

Luis commented on CAMEL-11174:
--

Hi [~dmvolod]:

Thank you for this pointer to gRPC/jersey bridge I will have a look at it.

Kindly
  Luis Oscar Trigueiros

> REST-DSL support for Google Protobuf
> 
>
> Key: CAMEL-11174
> URL: https://issues.apache.org/jira/browse/CAMEL-11174
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, camel-grpc
>Reporter: Luis
>Assignee: Dmitry Volodin
> Fix For: Future
>
>
> It would be nice to be able to output something other that just XML/JSON
> from a camel rest dsl route, namely Google Protobuf or Apache thrift.
> The idea would be that one could have addional MIME types add one could 
> define how they are handled.
> So for example application/x-protobuf could be handle by Protobuf.
> One example article that comes to mind is:
> https://javarants.com/using-jax-rs-with-protocol-buffers-for-high-performance-rest-apis-563ce40d15d9



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CAMEL-11174) REST-DSL support for Google Protobuf

[Dmitry Volodin (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CAMEL-11174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Volodin updated CAMEL-11174:
---
Fix Version/s: Future

> REST-DSL support for Google Protobuf
> 
>
> Key: CAMEL-11174
> URL: https://issues.apache.org/jira/browse/CAMEL-11174
> Project: Camel
>  Issue Type: New Feature
>  Components: camel-core, camel-grpc
>Reporter: Luis
>Assignee: Dmitry Volodin
> Fix For: Future
>
>
> It would be nice to be able to output something other that just XML/JSON
> from a camel rest dsl route, namely Google Protobuf or Apache thrift.
> The idea would be that one could have addional MIME types add one could 
> define how they are handled.
> So for example application/x-protobuf could be handle by Protobuf.
> One example article that comes to mind is:
> https://javarants.com/using-jax-rs-with-protocol-buffers-for-high-performance-rest-apis-563ce40d15d9



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11999) Cannot create queue/message for Azure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245381#comment-16245381
 ] 

ASF GitHub Bot commented on CAMEL-11999:


tdiesler opened a new pull request #2087: [CAMEL-11999] Cannot create 
queue/message for Azure
URL: https://github.com/apache/camel/pull/2087
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Cannot create queue/message for Azure
> -
>
> Key: CAMEL-11999
> URL: https://issues.apache.org/jira/browse/CAMEL-11999
> Project: Camel
>  Issue Type: Bug
>  Components: camel-azure
>Affects Versions: 2.20.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
> Fix For: 2.20.1
>
>
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1819



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CAMEL-11999) Cannot create queue/message for Azure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CAMEL-11999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245382#comment-16245382
 ] 

ASF GitHub Bot commented on CAMEL-11999:


GitHub user tdiesler opened a pull request:

https://github.com/apache/camel/pull/2087

[CAMEL-11999] Cannot create queue/message for Azure



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tdiesler/camel CAMEL-11999

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/2087.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2087


commit 517be1c23e3b5a9c00182953357d921a34df6d2a
Author: Thomas Diesler 
Date:   2017-11-09T05:55:27Z

[CAMEL-11999] Cannot create queue/message for Azure




> Cannot create queue/message for Azure
> -
>
> Key: CAMEL-11999
> URL: https://issues.apache.org/jira/browse/CAMEL-11999
> Project: Camel
>  Issue Type: Bug
>  Components: camel-azure
>Affects Versions: 2.20.0
>Reporter: Thomas Diesler
>Assignee: Thomas Diesler
> Fix For: 2.20.1
>
>
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1819



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)