[jira] [Updated] (CAMEL-16177) File stream cache problem with multicast parallel processing and encrypted stream
[ https://issues.apache.org/jira/browse/CAMEL-16177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-16177: - Fix Version/s: 3.9.0 > File stream cache problem with multicast parallel processing and encrypted > stream > - > > Key: CAMEL-16177 > URL: https://issues.apache.org/jira/browse/CAMEL-16177 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.25.3, 3.7.2 >Reporter: Franz Forsthofer >Priority: Major > Fix For: 2.25.2, 3.7.3, 3.8.0, 3.9.0 > > > If you use stream caching with file encryption in a camel route where you > have a multicast with several branches, then it the following errors can > happen in the message processing of the branch. > * When the message is processed in a branch you can get the following > exception:aused by: java.lang.ArrayIndexOutOfBoundsException: while trying to > load from index 16 of a byte (or boolean) array with length 16, loaded from > field com.sun.crypto.provider.CounterMode.encryptedCounter of an object > loaded from local variable 'this'aused by: > java.lang.ArrayIndexOutOfBoundsException: while trying to load from index 16 > of a byte (or boolean) array with length 16, loaded from field > com.sun.crypto.provider.CounterMode.encryptedCounter of an object loaded from > local variable 'this' at > com.sun.crypto.provider.CounterMode.implCrypt(CounterMode.java:190) at > com.sun.crypto.provider.CounterMode.crypt(CounterMode.java:178) at > com.sun.crypto.provider.CounterMode.decrypt(CounterMode.java:153) at > com.sun.crypto.provider.CipherCore.update(CipherCore.java:782) at > com.sun.crypto.provider.CipherCore.update(CipherCore.java:667) at > com.sun.crypto.provider.AESCipher.engineUpdate(AESCipher.java:380) at > javax.crypto.Cipher.update(Cipher.java:1835) at > javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:139) at > javax.crypto.CipherInputStream.read(CipherInputStream.java:199) at > org.apache.camel.converter.stream.FileInputStreamCache.read(FileInputStreamCache.java:139) > * or you get a damaged payload in the branch which is not correctly decrypted > The root cause of the problem is that the decryptor is not thread safe: If > two different FileInputStreamCache instances use the same decryptor in two > different threads at the same time, the above problems occur. > I will provide a patch for this problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-16177) File stream cache problem with multicast parallel processing and encrypted stream
[ https://issues.apache.org/jira/browse/CAMEL-16177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-16177: - Fix Version/s: 2.25.2 Affects Version/s: 2.25.3 > File stream cache problem with multicast parallel processing and encrypted > stream > - > > Key: CAMEL-16177 > URL: https://issues.apache.org/jira/browse/CAMEL-16177 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.25.3, 3.7.2 >Reporter: Franz Forsthofer >Priority: Major > Fix For: 2.25.2, 3.7.3, 3.8.0 > > > If you use stream caching with file encryption in a camel route where you > have a multicast with several branches, then it the following errors can > happen in the message processing of the branch. > * When the message is processed in a branch you can get the following > exception:aused by: java.lang.ArrayIndexOutOfBoundsException: while trying to > load from index 16 of a byte (or boolean) array with length 16, loaded from > field com.sun.crypto.provider.CounterMode.encryptedCounter of an object > loaded from local variable 'this'aused by: > java.lang.ArrayIndexOutOfBoundsException: while trying to load from index 16 > of a byte (or boolean) array with length 16, loaded from field > com.sun.crypto.provider.CounterMode.encryptedCounter of an object loaded from > local variable 'this' at > com.sun.crypto.provider.CounterMode.implCrypt(CounterMode.java:190) at > com.sun.crypto.provider.CounterMode.crypt(CounterMode.java:178) at > com.sun.crypto.provider.CounterMode.decrypt(CounterMode.java:153) at > com.sun.crypto.provider.CipherCore.update(CipherCore.java:782) at > com.sun.crypto.provider.CipherCore.update(CipherCore.java:667) at > com.sun.crypto.provider.AESCipher.engineUpdate(AESCipher.java:380) at > javax.crypto.Cipher.update(Cipher.java:1835) at > javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:139) at > javax.crypto.CipherInputStream.read(CipherInputStream.java:199) at > org.apache.camel.converter.stream.FileInputStreamCache.read(FileInputStreamCache.java:139) > * or you get a damaged payload in the branch which is not correctly decrypted > The root cause of the problem is that the decryptor is not thread safe: If > two different FileInputStreamCache instances use the same decryptor in two > different threads at the same time, the above problems occur. > I will provide a patch for this problem. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-16177) File stream cache problem with multicast parallel processing and encrypted stream
Franz Forsthofer created CAMEL-16177: Summary: File stream cache problem with multicast parallel processing and encrypted stream Key: CAMEL-16177 URL: https://issues.apache.org/jira/browse/CAMEL-16177 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 3.7.2 Reporter: Franz Forsthofer Fix For: 3.7.3, 3.8.0 If you use stream caching with file encryption in a camel route where you have a multicast with several branches, then it the following errors can happen in the message processing of the branch. * When the message is processed in a branch you can get the following exception:aused by: java.lang.ArrayIndexOutOfBoundsException: while trying to load from index 16 of a byte (or boolean) array with length 16, loaded from field com.sun.crypto.provider.CounterMode.encryptedCounter of an object loaded from local variable 'this'aused by: java.lang.ArrayIndexOutOfBoundsException: while trying to load from index 16 of a byte (or boolean) array with length 16, loaded from field com.sun.crypto.provider.CounterMode.encryptedCounter of an object loaded from local variable 'this' at com.sun.crypto.provider.CounterMode.implCrypt(CounterMode.java:190) at com.sun.crypto.provider.CounterMode.crypt(CounterMode.java:178) at com.sun.crypto.provider.CounterMode.decrypt(CounterMode.java:153) at com.sun.crypto.provider.CipherCore.update(CipherCore.java:782) at com.sun.crypto.provider.CipherCore.update(CipherCore.java:667) at com.sun.crypto.provider.AESCipher.engineUpdate(AESCipher.java:380) at javax.crypto.Cipher.update(Cipher.java:1835) at javax.crypto.CipherInputStream.getMoreData(CipherInputStream.java:139) at javax.crypto.CipherInputStream.read(CipherInputStream.java:199) at org.apache.camel.converter.stream.FileInputStreamCache.read(FileInputStreamCache.java:139) * or you get a damaged payload in the branch which is not correctly decrypted The root cause of the problem is that the decryptor is not thread safe: If two different FileInputStreamCache instances use the same decryptor in two different threads at the same time, the above problems occur. I will provide a patch for this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15557) Multicast parallel processing with timeout: Stream Cache file not deleted if CachedOutputStream created before timeout and writing to CachedOutputStream happens after ti
Franz Forsthofer created CAMEL-15557: Summary: Multicast parallel processing with timeout: Stream Cache file not deleted if CachedOutputStream created before timeout and writing to CachedOutputStream happens after timeout Key: CAMEL-15557 URL: https://issues.apache.org/jira/browse/CAMEL-15557 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 3.4.3, 2.25.2 Reporter: Franz Forsthofer Fix For: 3.4.4, 3.6.0, 2.25.3 If you have a route with a Multicast with parallel processing and a timeout and a sub-route in the multicast which is creating an OutputStreamCache before the timeout and is writing to the OutputStreamCache after the timeout then the created file is never deleted from the file system. Similar situation as described in https://issues.apache.org/jira/browse/CAMEL-15532. The difference to https://issues.apache.org/jira/browse/CAMEL-15532 is that the OutputStreamCache is created before the timeout; in CAMEL-15532 the OutputStreamCache was created after the timeout and also the writing to the OutputStreamCache happened after the timeout. With our current concept to determine the UnitOfWork which removes via the onDone event the created file, we can only determine the described situation and throw an exception. See provided patch. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-15532) Multicast parallel processing with timeout: Stream Cache file not deleted
Franz Forsthofer created CAMEL-15532: Summary: Multicast parallel processing with timeout: Stream Cache file not deleted Key: CAMEL-15532 URL: https://issues.apache.org/jira/browse/CAMEL-15532 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 3.5.0, 3.4.3, 2.25.2 Reporter: Franz Forsthofer Fix For: 3.4.4, 3.6.0, 2.25.3 If you have a route with a Multicast with parallel processing and a timeout and a sub-route in the multicast which is creating a StreamCache after the timeout then the created stream cache file is never deleted from the file system. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14972) Enricher does not reset stream cache for aggregator
Franz Forsthofer created CAMEL-14972: Summary: Enricher does not reset stream cache for aggregator Key: CAMEL-14972 URL: https://issues.apache.org/jira/browse/CAMEL-14972 Project: Camel Issue Type: Bug Components: camel-core Reporter: Franz Forsthofer Fix For: 3.3.0 If the enricher receives a stream cache as original body then the stream is consumed by the enrich endpoint. Therefore the stream cache must be reset before it is forwarded to the aggregator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14795) camel-mail: allow dynamic setting of token in order to be able to support OAUTH
[ https://issues.apache.org/jira/browse/CAMEL-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-14795: - Fix Version/s: 3.2.0 > camel-mail: allow dynamic setting of token in order to be able to support > OAUTH > --- > > Key: CAMEL-14795 > URL: https://issues.apache.org/jira/browse/CAMEL-14795 > Project: Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 3.2.0 >Reporter: Franz Forsthofer >Priority: Major > Fix For: 3.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > camel-mail uses java-mail. Meanwhile java-mail does support OAuth for imap > and smtp (see [https://javaee.github.io/javamail/OAuth2]). The OAuth access > tokens typically expire. The current camel-mail component does not allow to > dynamically read the password (=token), the password is fix set in the > configuration. Therefore it is not possible to update the password/token. > We improve the camel-mail component so that it is possible to dynamically > read the user and password/token, so that the OAuth use case can be supported. > Instead of setting the user and password on the configuration, you specify an > authenticator bean in the configuration. The authenticator method > public PasswordAuthentication getPasswordAuthentication() > will be called dynamically whenever a user/token (or password) is needed for > connecting to the mail server. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14795) camel-mail: allow dynamic setting of token in order to be able to support OAUTH
Franz Forsthofer created CAMEL-14795: Summary: camel-mail: allow dynamic setting of token in order to be able to support OAUTH Key: CAMEL-14795 URL: https://issues.apache.org/jira/browse/CAMEL-14795 Project: Camel Issue Type: Improvement Components: camel-mail Affects Versions: 3.2.0 Reporter: Franz Forsthofer camel-mail uses java-mail. Meanwhile java-mail does support OAuth for imap and smtp (see [https://javaee.github.io/javamail/OAuth2]). The OAuth access tokens typically expire. The current camel-mail component does not allow to dynamically read the password (=token), the password is fix set in the configuration. Therefore it is not possible to update the password/token. We improve the camel-mail component so that it is possible to dynamically read the user and password/token, so that the OAuth use case can be supported. Instead of setting the user and password on the configuration, you specify an authenticator bean in the configuration. The authenticator method public PasswordAuthentication getPasswordAuthentication() will be called dynamically whenever a user/token (or password) is needed for connecting to the mail server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-12181) XML Signature: '#' missing in ObjectReference attribute of XADES element DataObjectFormat
[
https://issues.apache.org/jira/browse/CAMEL-12181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-12181:
-
Fix Version/s: (was: 2.20.2)
2.20.3
> XML Signature: '#' missing in ObjectReference attribute of XADES element
> DataObjectFormat
> -
>
> Key: CAMEL-12181
> URL: https://issues.apache.org/jira/browse/CAMEL-12181
> Project: Camel
> Issue Type: Bug
> Components: camel-xmlsecurity
>Affects Versions: 2.18.5, 2.19.4, 2.20.1
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
>Priority: Major
> Fix For: 2.19.5, 2.20.3, 2.21.0
>
>
> If you create an XML Signature with a XADES element DataObjectFormat then you
> get currently an XML which is similar as shown in the following snippet:
> URI="#_4dccda23-2c67-487b-b7f2-30188bb089f7">
> ...
>
> ...
> {color:#00} ObjectReference="_1a612e6b-0da6-4695-a8f7-d189a47a7e05">{color}
> {color:#00} …{color}
> {color:#00}{color}
>
> {color:#00}The ObjectReference value
> "_1a612e6b-0da6-4695-a8f7-d189a47a7e05" is not a valid URI. The character
> '#' is missing at the beginning of the value{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12181) XML Signature: '#' missing in ObjectReference attribute of XADES element DataObjectFormat
Franz Forsthofer created CAMEL-12181:
Summary: XML Signature: '#' missing in ObjectReference attribute
of XADES element DataObjectFormat
Key: CAMEL-12181
URL: https://issues.apache.org/jira/browse/CAMEL-12181
Project: Camel
Issue Type: Bug
Components: camel-xmlsecurity
Affects Versions: 2.20.1, 2.19.4, 2.18.5
Reporter: Franz Forsthofer
Assignee: Franz Forsthofer
Fix For: 2.19.5, 2.20.2, 2.21.0
If you create an XML Signature with a XADES element DataObjectFormat then you
get currently an XML which is similar as shown in the following snippet:
...
...
{color:#00}{color}
{color:#00} …{color}
{color:#00}{color}
{color:#00}The ObjectReference value
"_1a612e6b-0da6-4695-a8f7-d189a47a7e05" is not a valid URI. The character '#'
is missing at the beginning of the value{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12075) Piling up of threads in iterating splitter in pararllel processing
[ https://issues.apache.org/jira/browse/CAMEL-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-12075: - Summary: Piling up of threads in iterating splitter in pararllel processing (was: Piling up of threads in iterating splitter in prarllel processing) > Piling up of threads in iterating splitter in pararllel processing > -- > > Key: CAMEL-12075 > URL: https://issues.apache.org/jira/browse/CAMEL-12075 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.5, 2.19.4, 2.20.1 >Reporter: Franz Forsthofer > Fix For: 2.19.5, 2.20.2, 2.21.0 > > > If you have a custom interating splitter which runs in parallel processing > and which throws a RuntimeException either in the "hasNext" or "next" method > after an aggregation thread was created then the aggregation thread will > never finish. > Therefore if the error occurs mulitple times the aggregatgor threads pile up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CAMEL-12075) Piling up of threads in iterating splitter in prarllel processing
[ https://issues.apache.org/jira/browse/CAMEL-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285606#comment-16285606 ] Franz Forsthofer edited comment on CAMEL-12075 at 12/11/17 7:45 AM: I will provide a GitHup pull request for the master branch. If this request is accepted, I can make the patches for the older versions 2.20.2 and 2.19.5. was (Author: forsthofer): I will provide a GitHup pull request. > Piling up of threads in iterating splitter in prarllel processing > - > > Key: CAMEL-12075 > URL: https://issues.apache.org/jira/browse/CAMEL-12075 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.5, 2.19.4, 2.20.1 >Reporter: Franz Forsthofer > Fix For: 2.19.5, 2.20.2, 2.21.0 > > > If you have a custom interating splitter which runs in parallel processing > and which throws a RuntimeException either in the "hasNext" or "next" method > after an aggregation thread was created then the aggregation thread will > never finish. > Therefore if the error occurs mulitple times the aggregatgor threads pile up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-12075) Piling up of threads in iterating splitter in prarllel processing
Franz Forsthofer created CAMEL-12075: Summary: Piling up of threads in iterating splitter in prarllel processing Key: CAMEL-12075 URL: https://issues.apache.org/jira/browse/CAMEL-12075 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.20.1, 2.19.4, 2.18.5 Reporter: Franz Forsthofer Fix For: 2.19.5, 2.20.2, 2.21.0 If you have a custom interating splitter which runs in parallel processing and which throws a RuntimeException either in the "hasNext" or "next" method after an aggregation thread was created then the aggregation thread will never finish. Therefore if the error occurs mulitple times the aggregatgor threads pile up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-12075) Piling up of threads in iterating splitter in prarllel processing
[ https://issues.apache.org/jira/browse/CAMEL-12075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285606#comment-16285606 ] Franz Forsthofer commented on CAMEL-12075: -- I will provide a GitHup pull request. > Piling up of threads in iterating splitter in prarllel processing > - > > Key: CAMEL-12075 > URL: https://issues.apache.org/jira/browse/CAMEL-12075 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.18.5, 2.19.4, 2.20.1 >Reporter: Franz Forsthofer > Fix For: 2.19.5, 2.20.2, 2.21.0 > > > If you have a custom interating splitter which runs in parallel processing > and which throws a RuntimeException either in the "hasNext" or "next" method > after an aggregation thread was created then the aggregation thread will > never finish. > Therefore if the error occurs mulitple times the aggregatgor threads pile up. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-11438) New crypto component CMS (Cryptographic Message Syntax)
[ https://issues.apache.org/jira/browse/CAMEL-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-11438. -- Resolution: Implemented I improved the documentation file src\main\docs\crypto-cms-component.adoc. > New crypto component CMS (Cryptographic Message Syntax) > --- > > Key: CAMEL-11438 > URL: https://issues.apache.org/jira/browse/CAMEL-11438 > Project: Camel > Issue Type: New Feature > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.20.0 > > > The Cryptographic Message Syntax (CMS) is a well accepted standard for > encryption/decryption and signing/verifying of messages. It is specified in > RFC5652. We will introduce a new component which will support the encryption > and signing of messages as well as the decryption and verifying of messages > according to the CMS standard. > In more detail, we will support the the Content Types "Enveloped Data" and > "Signed Data". "Enveloped Data" will be supported with Key Transport. > The new component will use the Bouncy Caslte JCE library and the Bouncy > Castle PKIX library containing support for CMS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11438) New crypto component CMS (Cryptographic Message Syntax)
[ https://issues.apache.org/jira/browse/CAMEL-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-11438: - Description: The Cryptographic Message Syntax (CMS) is a well accepted standard for encryption/decryption and signing/verifying of messages. It is specified in RFC5652. We will introduce a new component which will support the encryption and signing of messages as well as the decryption and verifying of messages according to the CMS standard. In more detail, we will support the the Content Types "Enveloped Data" and "Signed Data". "Enveloped Data" will be supported with Key Transport. The new component will use the Bouncy Caslte JCE library and the Bouncy Castle PKIX library containing support for CMS. was: The Cryptographic Message Syntax (CMS) is a well accepted standard for encryption/decryption and signing/verifying of messages. It is specified in RFC5652. We will introduce a new component which will support the encryption and signing of messages as well as the decryption and verifying of messages according to the CMS standard. The new component will use the Bouncy Caslte JCE library and the Bouncy Castle PKIX library containing support for CMS. > New crypto component CMS (Cryptographic Message Syntax) > --- > > Key: CAMEL-11438 > URL: https://issues.apache.org/jira/browse/CAMEL-11438 > Project: Camel > Issue Type: New Feature > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.20.0 > > > The Cryptographic Message Syntax (CMS) is a well accepted standard for > encryption/decryption and signing/verifying of messages. It is specified in > RFC5652. We will introduce a new component which will support the encryption > and signing of messages as well as the decryption and verifying of messages > according to the CMS standard. > In more detail, we will support the the Content Types "Enveloped Data" and > "Signed Data". "Enveloped Data" will be supported with Key Transport. > The new component will use the Bouncy Caslte JCE library and the Bouncy > Castle PKIX library containing support for CMS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11438) New crypto component CMS (Cryptographic Message Syntax)
[ https://issues.apache.org/jira/browse/CAMEL-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16132059#comment-16132059 ] Franz Forsthofer commented on CAMEL-11438: -- Hello Claus and Viral, thank you for reminding me. I have made the necessary adaptations. I will soon also improve the general MD documentation. Regards Franz > New crypto component CMS (Cryptographic Message Syntax) > --- > > Key: CAMEL-11438 > URL: https://issues.apache.org/jira/browse/CAMEL-11438 > Project: Camel > Issue Type: New Feature > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.20.0 > > > The Cryptographic Message Syntax (CMS) is a well accepted standard for > encryption/decryption and signing/verifying of messages. It is specified in > RFC5652. We will introduce a new component which will support the encryption > and signing of messages as well as the decryption and verifying of messages > according to the CMS standard. > The new component will use the Bouncy Caslte JCE library and the Bouncy > Castle PKIX library containing support for CMS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (CAMEL-11438) New crypto component CMS (Cryptographic Message Syntax)
[ https://issues.apache.org/jira/browse/CAMEL-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-11438 started by Franz Forsthofer. > New crypto component CMS (Cryptographic Message Syntax) > --- > > Key: CAMEL-11438 > URL: https://issues.apache.org/jira/browse/CAMEL-11438 > Project: Camel > Issue Type: New Feature > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.20.0 > > > The Cryptographic Message Syntax (CMS) is a well accepted standard for > encryption/decryption and signing/verifying of messages. It is specified in > RFC5652. We will introduce a new component which will support the encryption > and signing of messages as well as the decryption and verifying of messages > according to the CMS standard. > The new component will use the Bouncy Caslte JCE library and the Bouncy > Castle PKIX library containing support for CMS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11438) New crypto component CMS (Cryptographic Message Syntax)
[ https://issues.apache.org/jira/browse/CAMEL-11438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-11438: - Component/s: camel-crypto > New crypto component CMS (Cryptographic Message Syntax) > --- > > Key: CAMEL-11438 > URL: https://issues.apache.org/jira/browse/CAMEL-11438 > Project: Camel > Issue Type: New Feature > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.20.0 > > > The Cryptographic Message Syntax (CMS) is a well accepted standard for > encryption/decryption and signing/verifying of messages. It is specified in > RFC5652. We will introduce a new component which will support the encryption > and signing of messages as well as the decryption and verifying of messages > according to the CMS standard. > The new component will use the Bouncy Caslte JCE library and the Bouncy > Castle PKIX library containing support for CMS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11438) New crypto component CMS (Cryptographic Message Syntax)
Franz Forsthofer created CAMEL-11438: Summary: New crypto component CMS (Cryptographic Message Syntax) Key: CAMEL-11438 URL: https://issues.apache.org/jira/browse/CAMEL-11438 Project: Camel Issue Type: New Feature Reporter: Franz Forsthofer Assignee: Franz Forsthofer Fix For: 2.20.0 The Cryptographic Message Syntax (CMS) is a well accepted standard for encryption/decryption and signing/verifying of messages. It is specified in RFC5652. We will introduce a new component which will support the encryption and signing of messages as well as the decryption and verifying of messages according to the CMS standard. The new component will use the Bouncy Caslte JCE library and the Bouncy Castle PKIX library containing support for CMS. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-11063) PGP Decryptor does not make Integrity check
[ https://issues.apache.org/jira/browse/CAMEL-11063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-11063. -- Resolution: Fixed > PGP Decryptor does not make Integrity check > --- > > Key: CAMEL-11063 > URL: https://issues.apache.org/jira/browse/CAMEL-11063 > Project: Camel > Issue Type: Bug > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.7, 2.18.4, 2.19.0 > > > A PGP Message can contain a Modification Code Detection Packet (MDC) which > contains a hash value of the clear text data. This hash value can be used to > check the integrity of the clear text data. Currently this check is not > executed in the unmarshall method of the PGP Data Formater. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (CAMEL-11063) PGP Decryptor does not make Integrity check
[ https://issues.apache.org/jira/browse/CAMEL-11063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer reassigned CAMEL-11063: Assignee: Franz Forsthofer > PGP Decryptor does not make Integrity check > --- > > Key: CAMEL-11063 > URL: https://issues.apache.org/jira/browse/CAMEL-11063 > Project: Camel > Issue Type: Bug > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.7, 2.18.4, 2.19.0 > > > A PGP Message can contain a Modification Code Detection Packet (MDC) which > contains a hash value of the clear text data. This hash value can be used to > check the integrity of the clear text data. Currently this check is not > executed in the unmarshall method of the PGP Data Formater. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-11063) PGP Decryptor does not make Integrity check
Franz Forsthofer created CAMEL-11063: Summary: PGP Decryptor does not make Integrity check Key: CAMEL-11063 URL: https://issues.apache.org/jira/browse/CAMEL-11063 Project: Camel Issue Type: Bug Components: camel-crypto Reporter: Franz Forsthofer Fix For: 2.17.7, 2.18.4, 2.19.0 A PGP Message can contain a Modification Code Detection Packet (MDC) which contains a hash value of the clear text data. This hash value can be used to check the integrity of the clear text data. Currently this check is not executed in the unmarshall method of the PGP Data Formater. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (CAMEL-10894) XML Validator: Improve DTD handling
[ https://issues.apache.org/jira/browse/CAMEL-10894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890187#comment-15890187 ] Franz Forsthofer edited comment on CAMEL-10894 at 3/1/17 1:48 PM: -- I checked 2.17.x and 2.18.x and I saw that the fixes form Tomashisa and Stephan Sioana are there. Thank you Tomohisa and Stephan. was (Author: forsthofer): I checked 2.17.x and 2.18.x and I saw that the fixes form Tomashisa and Stephan Sioana are there. Thank you Tomohisa ans Stephan. > XML Validator: Improve DTD handling > --- > > Key: CAMEL-10894 > URL: https://issues.apache.org/jira/browse/CAMEL-10894 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.17.4, 2.17.5, 2.18.0, > 2.18.1, 2.18.2 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.6, 2.18.3, 2.19.0 > > > The DTD handling in the XML Validator is not correct for StreamSources -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10894) XML Validator: Improve DTD handling
[ https://issues.apache.org/jira/browse/CAMEL-10894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15890187#comment-15890187 ] Franz Forsthofer commented on CAMEL-10894: -- I checked 2.17.x and 2.18.x and I saw that the fixes form Tomashisa and Stephan Sioana are there. Thank you Tomohisa ans Stephan. > XML Validator: Improve DTD handling > --- > > Key: CAMEL-10894 > URL: https://issues.apache.org/jira/browse/CAMEL-10894 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.17.4, 2.17.5, 2.18.0, > 2.18.1, 2.18.2 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.6, 2.18.3, 2.19.0 > > > The DTD handling in the XML Validator is not correct for StreamSources -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CAMEL-10894) XML Validator: Improve DTD handling
[ https://issues.apache.org/jira/browse/CAMEL-10894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-10894. -- Resolution: Fixed > XML Validator: Improve DTD handling > --- > > Key: CAMEL-10894 > URL: https://issues.apache.org/jira/browse/CAMEL-10894 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.17.4, 2.17.5, 2.18.0, > 2.18.1, 2.18.2 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.6, 2.18.3, 2.19.0 > > > The DTD handling in the XML Validator is not correct for StreamSources -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (CAMEL-10894) XML Validator: Improve DTD handling
[ https://issues.apache.org/jira/browse/CAMEL-10894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-10894 started by Franz Forsthofer. > XML Validator: Improve DTD handling > --- > > Key: CAMEL-10894 > URL: https://issues.apache.org/jira/browse/CAMEL-10894 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.17.0, 2.17.1, 2.17.2, 2.17.3, 2.17.4, 2.17.5, 2.18.0, > 2.18.1, 2.18.2 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.6, 2.18.3, 2.19.0 > > > The DTD handling in the XML Validator is not correct for StreamSources -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CAMEL-10894) XML Validator: Improve DTD handling
Franz Forsthofer created CAMEL-10894: Summary: XML Validator: Improve DTD handling Key: CAMEL-10894 URL: https://issues.apache.org/jira/browse/CAMEL-10894 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.18.2, 2.18.1, 2.18.0, 2.17.5, 2.17.4, 2.17.3, 2.17.2, 2.17.1, 2.17.0 Reporter: Franz Forsthofer Assignee: Franz Forsthofer Fix For: 2.17.6, 2.18.3, 2.19.0 The DTD handling in the XML Validator is not correct for StreamSources -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CAMEL-10368) Unused deflater in ZipDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15545175#comment-15545175
]
Franz Forsthofer commented on CAMEL-10368:
--
Hello Andrea,
it is only a very small change. So I have committed. I hope this is no problem
for you. Sorry for any inconvenience.
> Unused deflater in ZipDataFormat
>
>
> Key: CAMEL-10368
> URL: https://issues.apache.org/jira/browse/CAMEL-10368
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.19.0, 2.17.4, 2.18.1
>
>
> In the ZipDataForamt class you find
> final Deflater deflater = new Deflater(compressionLevel);
> final DeflaterOutputStream zipOutput = new
> DeflaterOutputStream(stream, new Deflater(compressionLevel));
> try {
> IOHelper.copy(is, zipOutput);
> } finally {
> IOHelper.close(is, zipOutput);
>
> /*
> * As we create the Deflater our self and do not use the stream
> default
> * (see {@link
> java.util.zip.DeflaterOutputStream#usesDefaultDeflater})
> * we need to close the Deflater to not risk a OutOfMemoryException
> * in native code parts (see {@link java.util.zip.Deflater#end})
> */
> deflater.end();
> }
> the deflater variable should be used in the DeflaterOutputStream
> final DeflaterOutputStream zipOutput = new DeflaterOutputStream(stream,
> deflater);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10368) Unused deflater in ZipDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-10368:
-
Fix Version/s: (was: 2.18.0)
2.18.1
2.19.0
> Unused deflater in ZipDataFormat
>
>
> Key: CAMEL-10368
> URL: https://issues.apache.org/jira/browse/CAMEL-10368
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.19.0, 2.17.4, 2.18.1
>
>
> In the ZipDataForamt class you find
> final Deflater deflater = new Deflater(compressionLevel);
> final DeflaterOutputStream zipOutput = new
> DeflaterOutputStream(stream, new Deflater(compressionLevel));
> try {
> IOHelper.copy(is, zipOutput);
> } finally {
> IOHelper.close(is, zipOutput);
>
> /*
> * As we create the Deflater our self and do not use the stream
> default
> * (see {@link
> java.util.zip.DeflaterOutputStream#usesDefaultDeflater})
> * we need to close the Deflater to not risk a OutOfMemoryException
> * in native code parts (see {@link java.util.zip.Deflater#end})
> */
> deflater.end();
> }
> the deflater variable should be used in the DeflaterOutputStream
> final DeflaterOutputStream zipOutput = new DeflaterOutputStream(stream,
> deflater);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CAMEL-10368) Unused deflater in ZipDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer closed CAMEL-10368.
Resolution: Fixed
> Unused deflater in ZipDataFormat
>
>
> Key: CAMEL-10368
> URL: https://issues.apache.org/jira/browse/CAMEL-10368
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.19.0, 2.17.4, 2.18.1
>
>
> In the ZipDataForamt class you find
> final Deflater deflater = new Deflater(compressionLevel);
> final DeflaterOutputStream zipOutput = new
> DeflaterOutputStream(stream, new Deflater(compressionLevel));
> try {
> IOHelper.copy(is, zipOutput);
> } finally {
> IOHelper.close(is, zipOutput);
>
> /*
> * As we create the Deflater our self and do not use the stream
> default
> * (see {@link
> java.util.zip.DeflaterOutputStream#usesDefaultDeflater})
> * we need to close the Deflater to not risk a OutOfMemoryException
> * in native code parts (see {@link java.util.zip.Deflater#end})
> */
> deflater.end();
> }
> the deflater variable should be used in the DeflaterOutputStream
> final DeflaterOutputStream zipOutput = new DeflaterOutputStream(stream,
> deflater);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-10368) Unused deflater in ZipDataFormat
[
https://issues.apache.org/jira/browse/CAMEL-10368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-10368 started by Franz Forsthofer.
> Unused deflater in ZipDataFormat
>
>
> Key: CAMEL-10368
> URL: https://issues.apache.org/jira/browse/CAMEL-10368
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.18.0, 2.17.4
>
>
> In the ZipDataForamt class you find
> final Deflater deflater = new Deflater(compressionLevel);
> final DeflaterOutputStream zipOutput = new
> DeflaterOutputStream(stream, new Deflater(compressionLevel));
> try {
> IOHelper.copy(is, zipOutput);
> } finally {
> IOHelper.close(is, zipOutput);
>
> /*
> * As we create the Deflater our self and do not use the stream
> default
> * (see {@link
> java.util.zip.DeflaterOutputStream#usesDefaultDeflater})
> * we need to close the Deflater to not risk a OutOfMemoryException
> * in native code parts (see {@link java.util.zip.Deflater#end})
> */
> deflater.end();
> }
> the deflater variable should be used in the DeflaterOutputStream
> final DeflaterOutputStream zipOutput = new DeflaterOutputStream(stream,
> deflater);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-10368) Unused deflater in ZipDataFormat
Franz Forsthofer created CAMEL-10368:
Summary: Unused deflater in ZipDataFormat
Key: CAMEL-10368
URL: https://issues.apache.org/jira/browse/CAMEL-10368
Project: Camel
Issue Type: Bug
Components: camel-core
Reporter: Franz Forsthofer
Assignee: Franz Forsthofer
Fix For: 2.18.0, 2.17.4
In the ZipDataForamt class you find
final Deflater deflater = new Deflater(compressionLevel);
final DeflaterOutputStream zipOutput = new DeflaterOutputStream(stream,
new Deflater(compressionLevel));
try {
IOHelper.copy(is, zipOutput);
} finally {
IOHelper.close(is, zipOutput);
/*
* As we create the Deflater our self and do not use the stream
default
* (see {@link
java.util.zip.DeflaterOutputStream#usesDefaultDeflater})
* we need to close the Deflater to not risk a OutOfMemoryException
* in native code parts (see {@link java.util.zip.Deflater#end})
*/
deflater.end();
}
the deflater variable should be used in the DeflaterOutputStream
final DeflaterOutputStream zipOutput = new DeflaterOutputStream(stream,
deflater);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer closed CAMEL-9572.
---
Resolution: Fixed
refactoring done
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-9572 started by Franz Forsthofer.
---
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer reopened CAMEL-9572:
-
The current clearCachedSchema method re-reads the schema document in binary
format and then sets the object model of the schema to null so that in the next
process call the object model is re-built from the read binary.
Suppose that the schema document was deleted and now the clearCachedSchema
method is called in order to refresh the cached object model. In this case the
re-read method will throw a "not found" exception and will not update the cache.
However, in this case one expects that the cache is invalidated and that during
the next process call an error occurs because the schema document was deleted.
Therefore the clear cache method should only clear the object model and not
re-read the document. The document shall be re-read during the next process
call.
This would also be in consistency with the treatment in the XSLT component.
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9580) XSLT Component: Support custom URI resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer resolved CAMEL-9580.
-
Resolution: Fixed
wiki updated
> XSLT Component: Support custom URI resolver which depends on dynamic resource
> URI of the endpoint
> -
>
> Key: CAMEL-9580
> URL: https://issues.apache.org/jira/browse/CAMEL-9580
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
>
> The XSLT component allows already specifying custom URI resolvers via the
> parameter uriResolver. However, when your custom URI resolver depends on the
> dynamic URI of the endpoint then the current solution is not sufficient.
> Suppose you have a dynamically created XSLT endpoint, like
>
> xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
>
> where the resource URI of the XSLT document is also dynamic (in the example
> via the header XSLT_File). In this case you cannot hand-over the dynamic
> resource URI to the custom URI resolver.
> The contribution solves this problem by introducing a new parameter
> uriResolverFactory where you can specify a factory which implements the method
> URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI.
> We also support that the resource URI factory can be set on the component so
> that you must not set the factory on each endpoint.
> Further advantage of the new approach is that you can now easily extend the
> default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
> also depends on the resource URI of the endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9580) XSLT Component: Support custom URI resolver which depends on dynamic resource URI of the endpoint
Franz Forsthofer created CAMEL-9580:
---
Summary: XSLT Component: Support custom URI resolver which depends
on dynamic resource URI of the endpoint
Key: CAMEL-9580
URL: https://issues.apache.org/jira/browse/CAMEL-9580
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Franz Forsthofer
Assignee: Franz Forsthofer
Fix For: 2.17.0
The XSLT component allows already specifying custom URI resolvers via the
parameter uriResolver. However, when your custom URI resolver depends on the
dynamic URI of the endpoint then the current solution is not sufficient.
Suppose you have a dynamically created XSLT endpoint, like
xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
where the resource URO of the XSLT document is also dynamic (in the example via
the header XSLT_File). In this case you cannot hand-over the dynamic resource
URI to the custom URI resolver.
The contribution solves this problem by introducing a new parameter
uriResolverFactory where you can specify a factdory which implements the method
URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
This method is called when the endpoint is created and gives you access to the
endpoint resource URI.
We also support that the resource URI factory can be set on the component so
that you must not set the factory on each endpoint.
Further advantage of the new approach is that you can now easily extend the
default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
also depends on the resource URI of the endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9580) XSLT Component: Support custom URI resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-9580:
Description:
The XSLT component allows already specifying custom URI resolvers via the
parameter uriResolver. However, when your custom URI resolver depends on the
dynamic URI of the endpoint then the current solution is not sufficient.
Suppose you have a dynamically created XSLT endpoint, like
xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
where the resource URI of the XSLT document is also dynamic (in the example via
the header XSLT_File). In this case you cannot hand-over the dynamic resource
URI to the custom URI resolver.
The contribution solves this problem by introducing a new parameter
uriResolverFactory where you can specify a factdory which implements the method
URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
This method is called when the endpoint is created and gives you access to the
endpoint resource URI.
We also support that the resource URI factory can be set on the component so
that you must not set the factory on each endpoint.
Further advantage of the new approach is that you can now easily extend the
default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
also depends on the resource URI of the endpoint.
was:
The XSLT component allows already specifying custom URI resolvers via the
parameter uriResolver. However, when your custom URI resolver depends on the
dynamic URI of the endpoint then the current solution is not sufficient.
Suppose you have a dynamically created XSLT endpoint, like
xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
where the resource URO of the XSLT document is also dynamic (in the example via
the header XSLT_File). In this case you cannot hand-over the dynamic resource
URI to the custom URI resolver.
The contribution solves this problem by introducing a new parameter
uriResolverFactory where you can specify a factdory which implements the method
URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
This method is called when the endpoint is created and gives you access to the
endpoint resource URI.
We also support that the resource URI factory can be set on the component so
that you must not set the factory on each endpoint.
Further advantage of the new approach is that you can now easily extend the
default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
also depends on the resource URI of the endpoint.
> XSLT Component: Support custom URI resolver which depends on dynamic resource
> URI of the endpoint
> -
>
> Key: CAMEL-9580
> URL: https://issues.apache.org/jira/browse/CAMEL-9580
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
>
> The XSLT component allows already specifying custom URI resolvers via the
> parameter uriResolver. However, when your custom URI resolver depends on the
> dynamic URI of the endpoint then the current solution is not sufficient.
> Suppose you have a dynamically created XSLT endpoint, like
>
> xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
>
> where the resource URI of the XSLT document is also dynamic (in the example
> via the header XSLT_File). In this case you cannot hand-over the dynamic
> resource URI to the custom URI resolver.
> The contribution solves this problem by introducing a new parameter
> uriResolverFactory where you can specify a factdory which implements the
> method
> URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI.
> We also support that the resource URI factory can be set on the component so
> that you must not set the factory on each endpoint.
> Further advantage of the new approach is that you can now easily extend the
> default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
> also depends on the resource URI of the endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9580) XSLT Component: Support custom URI resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15137160#comment-15137160
]
Franz Forsthofer commented on CAMEL-9580:
-
I made a similar enhancement for the XSLT component as I have done for the
Validator component. See https://issues.apache.org/jira/browse/CAMEL-9572
> XSLT Component: Support custom URI resolver which depends on dynamic resource
> URI of the endpoint
> -
>
> Key: CAMEL-9580
> URL: https://issues.apache.org/jira/browse/CAMEL-9580
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
>
> The XSLT component allows already specifying custom URI resolvers via the
> parameter uriResolver. However, when your custom URI resolver depends on the
> dynamic URI of the endpoint then the current solution is not sufficient.
> Suppose you have a dynamically created XSLT endpoint, like
>
> xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
>
> where the resource URI of the XSLT document is also dynamic (in the example
> via the header XSLT_File). In this case you cannot hand-over the dynamic
> resource URI to the custom URI resolver.
> The contribution solves this problem by introducing a new parameter
> uriResolverFactory where you can specify a factory which implements the method
> URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI.
> We also support that the resource URI factory can be set on the component so
> that you must not set the factory on each endpoint.
> Further advantage of the new approach is that you can now easily extend the
> default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
> also depends on the resource URI of the endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (CAMEL-9580) XSLT Component: Support custom URI resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-9580 started by Franz Forsthofer.
---
> XSLT Component: Support custom URI resolver which depends on dynamic resource
> URI of the endpoint
> -
>
> Key: CAMEL-9580
> URL: https://issues.apache.org/jira/browse/CAMEL-9580
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
>
> The XSLT component allows already specifying custom URI resolvers via the
> parameter uriResolver. However, when your custom URI resolver depends on the
> dynamic URI of the endpoint then the current solution is not sufficient.
> Suppose you have a dynamically created XSLT endpoint, like
>
> xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
>
> where the resource URI of the XSLT document is also dynamic (in the example
> via the header XSLT_File). In this case you cannot hand-over the dynamic
> resource URI to the custom URI resolver.
> The contribution solves this problem by introducing a new parameter
> uriResolverFactory where you can specify a factory which implements the method
> URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI.
> We also support that the resource URI factory can be set on the component so
> that you must not set the factory on each endpoint.
> Further advantage of the new approach is that you can now easily extend the
> default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
> also depends on the resource URI of the endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9580) XSLT Component: Support custom URI resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-9580:
Description:
The XSLT component allows already specifying custom URI resolvers via the
parameter uriResolver. However, when your custom URI resolver depends on the
dynamic URI of the endpoint then the current solution is not sufficient.
Suppose you have a dynamically created XSLT endpoint, like
xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
where the resource URI of the XSLT document is also dynamic (in the example via
the header XSLT_File). In this case you cannot hand-over the dynamic resource
URI to the custom URI resolver.
The contribution solves this problem by introducing a new parameter
uriResolverFactory where you can specify a factory which implements the method
URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
This method is called when the endpoint is created and gives you access to the
endpoint resource URI.
We also support that the resource URI factory can be set on the component so
that you must not set the factory on each endpoint.
Further advantage of the new approach is that you can now easily extend the
default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
also depends on the resource URI of the endpoint.
was:
The XSLT component allows already specifying custom URI resolvers via the
parameter uriResolver. However, when your custom URI resolver depends on the
dynamic URI of the endpoint then the current solution is not sufficient.
Suppose you have a dynamically created XSLT endpoint, like
xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
where the resource URI of the XSLT document is also dynamic (in the example via
the header XSLT_File). In this case you cannot hand-over the dynamic resource
URI to the custom URI resolver.
The contribution solves this problem by introducing a new parameter
uriResolverFactory where you can specify a factdory which implements the method
URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
This method is called when the endpoint is created and gives you access to the
endpoint resource URI.
We also support that the resource URI factory can be set on the component so
that you must not set the factory on each endpoint.
Further advantage of the new approach is that you can now easily extend the
default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
also depends on the resource URI of the endpoint.
> XSLT Component: Support custom URI resolver which depends on dynamic resource
> URI of the endpoint
> -
>
> Key: CAMEL-9580
> URL: https://issues.apache.org/jira/browse/CAMEL-9580
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
>
> The XSLT component allows already specifying custom URI resolvers via the
> parameter uriResolver. However, when your custom URI resolver depends on the
> dynamic URI of the endpoint then the current solution is not sufficient.
> Suppose you have a dynamically created XSLT endpoint, like
>
> xslt:${header.XSLT_FILE}?uriResolver=#uriResolver
>
> where the resource URI of the XSLT document is also dynamic (in the example
> via the header XSLT_File). In this case you cannot hand-over the dynamic
> resource URI to the custom URI resolver.
> The contribution solves this problem by introducing a new parameter
> uriResolverFactory where you can specify a factory which implements the method
> URIResolver createUriResolver(CamelContext camelContext, String resourceUri)
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI.
> We also support that the resource URI factory can be set on the component so
> that you must not set the factory on each endpoint.
> Further advantage of the new approach is that you can now easily extend the
> default resource resolver org.apache.camel.builder.xml.XsltUriResolver which
> also depends on the resource URI of the endpoint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-9572:
Attachment: (was:
0001-Validator-support-custom-resource-resolver-factory.patch)
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-9572:
Attachment: 0001-Validator-support-custom-resource-resolver-factory.patch
Hi Claus,
i made the changes requested by you. See attached patch.
Can I now check-ti in?
Best Regards Franz
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer resolved CAMEL-9572.
-
Resolution: Fixed
Wiki Page updated.
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-9572:
Description:
The validator endpoint allows already to specify custom resource resolvers, via
the parameter resourceResolver. However, there is a use case where this
functionality is not sufficient. If you have a dynamically created validator
endpoint, like
validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
where the resource URI of the XSD document is also dynamic (in the example via
the header XSD_FILE) and if your resource resolver depends on the resource URI
of the XSD document, then the current implementation gives you no solution for
this problem. You cannot hand-over the dynamic resource URI to the custom
resource resolver.
Therefore we introduce the new parameter resourceResolverFactory where you can
specify a factory which implements the method
LSResourceResolver createResourceResolver(CamelContext camelContext, String
rootResourceUri);
This method is called when the endpoint is created and gives you access to the
endpoint resource URI (parameter rootResourceUri).
Remark: resource resolvers need to have the root resource URI in the case of
relative URIs.
was:
The validator endpoint allows already to specify custom resource resolvers, via
the parameter resourceResolver. However, there is a use case where this
functionality is not sufficient. If you have a dynamically created validator
endpoint, like
}validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
where the resource URI of the XSD document is also dynamic (in the example via
the header XSD_FILE) and if your resource resolver depends on the resource URI
of the XSD document, then the current implementation gives you no solution for
this problem. You cannot hand-over the dynamic resource URI to the custom
resource resolver.
Therefore we introduce the new parameter resourceResolverFactory where you can
specify a factory which implements the method
LSResourceResolver createResourceResolver(CamelContext camelContext, String
rootResourceUri);
This method is called when the endpoint is created and gives you access to the
endpoint resource URI (parameter rootResourceUri).
Remark: resource resolvers need to have the root resource URI in the case of
relative URIs.
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135820#comment-15135820
]
Franz Forsthofer commented on CAMEL-9572:
-
Hi Claus,
what do you think about this feature. Can I check it in? I have commiter rights.
If you agree I would also submit a similar solution for the XSLT component.
Best Regards Franz
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
Franz Forsthofer created CAMEL-9572:
---
Summary: Validator Component: Support custom resource resolver
which depends on dynamic resource URI of the endpoint
Key: CAMEL-9572
URL: https://issues.apache.org/jira/browse/CAMEL-9572
Project: Camel
Issue Type: Improvement
Components: camel-core
Reporter: Franz Forsthofer
Assignee: Franz Forsthofer
Fix For: 2.17.0
The validator endpoint allows already to specify custom resource resolvers, via
the parameter resourceResolver. However, there is a use case where this
functionality is not sufficient. If you have a dynamically created validator
endpoint, like
}validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
where the resource URI of the XSD document is also dynamic (in the example via
the header XSD_FILE) and if your resource resolver depends on the resource URI
of the XSD document, then the current implementation gives you no solution for
this problem. You cannot hand-over the dynamic resource URI to the custom
resource resolver.
Therefore we introduce the new parameter resourceResolverFactory where you can
specify a factory which implements the method
LSResourceResolver createResourceResolver(CamelContext camelContext, String
rootResourceUri);
This method is called when the endpoint is created and gives you access to the
endpoint resource URI (parameter rootResourceUri).
Remark: resource resolvers need to have the root resource URI in the case of
relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-9572) Validator Component: Support custom resource resolver which depends on dynamic resource URI of the endpoint
[
https://issues.apache.org/jira/browse/CAMEL-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-9572:
Attachment: 0001-Validator-support-custom-resource-resolver-factory.patch
> Validator Component: Support custom resource resolver which depends on
> dynamic resource URI of the endpoint
> ---
>
> Key: CAMEL-9572
> URL: https://issues.apache.org/jira/browse/CAMEL-9572
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Franz Forsthofer
>Assignee: Franz Forsthofer
> Fix For: 2.17.0
>
> Attachments:
> 0001-Validator-support-custom-resource-resolver-factory.patch
>
>
> The validator endpoint allows already to specify custom resource resolvers,
> via the parameter resourceResolver. However, there is a use case where this
> functionality is not sufficient. If you have a dynamically created validator
> endpoint, like
>
>
> }validator:${header.XSD_FILE}?resourceResolver=#resourceResolver
>
> where the resource URI of the XSD document is also dynamic (in the example
> via the header XSD_FILE) and if your resource resolver depends on the
> resource URI of the XSD document, then the current implementation gives you
> no solution for this problem. You cannot hand-over the dynamic resource URI
> to the custom resource resolver.
> Therefore we introduce the new parameter resourceResolverFactory where you
> can specify a factory which implements the method
> LSResourceResolver createResourceResolver(CamelContext camelContext, String
> rootResourceUri);
> This method is called when the endpoint is created and gives you access to
> the endpoint resource URI (parameter rootResourceUri).
> Remark: resource resolvers need to have the root resource URI in the case of
> relative URIs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-9517) Validator Component: add clearCachedSchema method to ValidatorEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15098305#comment-15098305 ] Franz Forsthofer commented on CAMEL-9517: - Hi Claus, can you please have a look at this improvement. I saw that you made some changes in release 2.15 and 2.16. What do you think about it? I am committer and can do the final submit and I will update the wiki-page. Best Regards Franz > Validator Component: add clearCachedSchema method to ValidatorEndpoint > -- > > Key: CAMEL-9517 > URL: https://issues.apache.org/jira/browse/CAMEL-9517 > Project: Camel > Issue Type: Improvement >Affects Versions: 2.17.0 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > Attachments: > 0001-ValidatorEndpoint-method-clearCachedSchema-added.patch > > > Currently the ValidatorProcessor caches an object representation of the > schema and there is no possibility to invalidate the cache. This improvement > introduces the method clearCachedSchema on the Validator Endpoint with which > the cached schema is cleared so that on the next call the schema is reread. > The method is annotated with @ManagedOperation so that it can be called from > the JMX console. > The method can be used to update the schema in the endpoint when the > underlying schema file has changed. For example, you can implement a custom > class resolver which reads the schema file from a data base; whenever the > schema file is changed in the data base, then you can update the cached > schema with the above method without restarting the camel route. > A similar method exists for the XSLT component. See method > XsltEndpoint.clearCachedStylesheet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9517) Validator Component: add clearCachedSchema method to ValidatorEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-9517: Description: Currently the ValidatorProcessor caches an object representation of the schema and there is no possibility to invalidate the cache. This improvement introduces the method clearCachedSchema on the Validator Endpoint with which the cached schema is cleared so that on the next call the schema is reread. The method is annotated with @ManagedOperation so that it can be called from the JMX console. The method can be used to update the schema in the endpoint when the underlying schema file has changed. For example, you can implement a custom class resolver which reads the schema file from a data base; whenever the schema file is changed in the data base, then you can update the cached schema with the above method without restarting the camel route. A similar method exists for the XSLT component. See method XsltEndpoint.clearCachedStylesheet. was: Currently the ValidatorProcessor caches an object representation of the schema and there is no possibility to invalidate the cache. This improvement introduces the method clearCachedSchema on the Validator Endpoint with which the cached schema is cleared so that on the next call the schema is reread. The method is annotated with @ManagedOperation so that it can be called from the JMX console. The method can be used to update the schema in the endpoint when the underlying schema has changed. For example, you can implement a custom class resolver which reads the schema file from a data base; whenever the schema file is changed in the data base, then you can update the cached schema with the above method without restarting the camel route. A similar method exists for the XSLT component. See method XsltEndpoint.clearCachedStylesheet. > Validator Component: add clearCachedSchema method to ValidatorEndpoint > -- > > Key: CAMEL-9517 > URL: https://issues.apache.org/jira/browse/CAMEL-9517 > Project: Camel > Issue Type: Improvement >Affects Versions: 2.17.0 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > Attachments: > 0001-ValidatorEndpoint-method-clearCachedSchema-added.patch > > > Currently the ValidatorProcessor caches an object representation of the > schema and there is no possibility to invalidate the cache. This improvement > introduces the method clearCachedSchema on the Validator Endpoint with which > the cached schema is cleared so that on the next call the schema is reread. > The method is annotated with @ManagedOperation so that it can be called from > the JMX console. > The method can be used to update the schema in the endpoint when the > underlying schema file has changed. For example, you can implement a custom > class resolver which reads the schema file from a data base; whenever the > schema file is changed in the data base, then you can update the cached > schema with the above method without restarting the camel route. > A similar method exists for the XSLT component. See method > XsltEndpoint.clearCachedStylesheet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9517) Validator Component: add clearCachedSchema method to ValidatorEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-9517: Attachment: 0001-ValidatorEndpoint-method-clearCachedSchema-added.patch > Validator Component: add clearCachedSchema method to ValidatorEndpoint > -- > > Key: CAMEL-9517 > URL: https://issues.apache.org/jira/browse/CAMEL-9517 > Project: Camel > Issue Type: Improvement >Affects Versions: 2.17.0 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > Attachments: > 0001-ValidatorEndpoint-method-clearCachedSchema-added.patch > > > Currently the ValidatorProcessor caches an object representation of the > schema and there is no possibility to invalidate the cache. This improvement > introduces the method clearCachedSchema on the Validator Endpoint with which > the cached schema is cleared so that on the next call the schema is reread. > The method is annotated with @ManagedOperation so that it can be called from > the JMX console. > The method can be used to update the schema in the endpoint when the > underlying schema has changed. For example, you can implement a custom class > resolver which reads the schema file from a data base; whenever the schema > file is changed in the data base, then you can update the cached schema with > the above method without restarting the camel route. > A similar method exists for the XSLT component. See method > XsltEndpoint.clearCachedStylesheet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9517) Validator Component: add clearCachedSchema method to ValidatorEndpoint
Franz Forsthofer created CAMEL-9517: --- Summary: Validator Component: add clearCachedSchema method to ValidatorEndpoint Key: CAMEL-9517 URL: https://issues.apache.org/jira/browse/CAMEL-9517 Project: Camel Issue Type: Improvement Affects Versions: 2.17.0 Reporter: Franz Forsthofer Assignee: Franz Forsthofer Fix For: 2.17.0 Currently the ValidatorProcessor caches an object representation of the schema and there is no possibility to invalidate the cache. This improvement introduces the method clearCachedSchema on the Validator Endpoint with which the cached schema is cleared so that on the next call the schema is reread. The method is annotated with @ManagedOperation so that it can be called from the JMX console. The method can be used to update the schema in the endpoint when the underlying schema has changed. For example, you can implement a custom class resolver which reads the schema file from a data base; whenever the schema file is changed in the data base, then you can update the cached schema with the above method without restarting the camel route. A similar method exists for the XSLT component. See method XsltEndpoint.clearCachedStylesheet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9517) Validator Component: add clearCachedSchema method to ValidatorEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-9517: Component/s: camel-core > Validator Component: add clearCachedSchema method to ValidatorEndpoint > -- > > Key: CAMEL-9517 > URL: https://issues.apache.org/jira/browse/CAMEL-9517 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.17.0 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > Attachments: > 0001-ValidatorEndpoint-method-clearCachedSchema-added.patch > > > Currently the ValidatorProcessor caches an object representation of the > schema and there is no possibility to invalidate the cache. This improvement > introduces the method clearCachedSchema on the Validator Endpoint with which > the cached schema is cleared so that on the next call the schema is reread. > The method is annotated with @ManagedOperation so that it can be called from > the JMX console. > The method can be used to update the schema in the endpoint when the > underlying schema file has changed. For example, you can implement a custom > class resolver which reads the schema file from a data base; whenever the > schema file is changed in the data base, then you can update the cached > schema with the above method without restarting the camel route. > A similar method exists for the XSLT component. See method > XsltEndpoint.clearCachedStylesheet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-9517) Validator Component: add clearCachedSchema method to ValidatorEndpoint
[ https://issues.apache.org/jira/browse/CAMEL-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer closed CAMEL-9517. --- Resolution: Resolved Wiki updated > Validator Component: add clearCachedSchema method to ValidatorEndpoint > -- > > Key: CAMEL-9517 > URL: https://issues.apache.org/jira/browse/CAMEL-9517 > Project: Camel > Issue Type: Improvement > Components: camel-core >Affects Versions: 2.17.0 >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > Attachments: > 0001-ValidatorEndpoint-method-clearCachedSchema-added.patch > > > Currently the ValidatorProcessor caches an object representation of the > schema and there is no possibility to invalidate the cache. This improvement > introduces the method clearCachedSchema on the Validator Endpoint with which > the cached schema is cleared so that on the next call the schema is reread. > The method is annotated with @ManagedOperation so that it can be called from > the JMX console. > The method can be used to update the schema in the endpoint when the > underlying schema file has changed. For example, you can implement a custom > class resolver which reads the schema file from a data base; whenever the > schema file is changed in the data base, then you can update the cached > schema with the above method without restarting the camel route. > A similar method exists for the XSLT component. See method > XsltEndpoint.clearCachedStylesheet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9306) XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform Methods
Franz Forsthofer created CAMEL-9306: --- Summary: XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform Methods Key: CAMEL-9306 URL: https://issues.apache.org/jira/browse/CAMEL-9306 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Franz Forsthofer Assignee: Franz Forsthofer Fix For: 2.17.0 In the XML Signature component you can define transform methods which are applied to the XML document before the signature is calculated (see configuration option "transformMethods" in the XML Signer). The definition of these transform methods is done either via POs in the java DSL or via beans in the Spring XML a list of such transformations. We want to offer also the possiblity that you can specify the transformations via the header "CamelXmlSignatureTransformMethods". The headeer value shall contain a comma separated list of transformation algorithms. The header approach will not allow parameters for the transformation methods. However the header approach is more simpler then the approach via POs or beans. The header overwrites the configuration option "transformMethods". Example for Header Value: "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9306) XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform Methods
[ https://issues.apache.org/jira/browse/CAMEL-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-9306: Description: In the XML Signature component you can define transform methods which are applied to the XML document before the signature is calculated (see configuration option "transformMethods" in the XML Signer). The definition of these transform methods is done either via POs in the java DSL or via beans in the Spring XML a list of such transformations. We want to offer also the possiblity that you can specify the transformations via the header "CamelXmlSignatureTransformMethods". The header value shall contain a comma separated list of transformation algorithms. The header approach will not allow parameters for the transformation methods. However the header approach is more simpler then the approach via POs or beans. The header overwrites the configuration option "transformMethods". Example for Header Value: "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; was: In the XML Signature component you can define transform methods which are applied to the XML document before the signature is calculated (see configuration option "transformMethods" in the XML Signer). The definition of these transform methods is done either via POs in the java DSL or via beans in the Spring XML a list of such transformations. We want to offer also the possiblity that you can specify the transformations via the header "CamelXmlSignatureTransformMethods". The headeer value shall contain a comma separated list of transformation algorithms. The header approach will not allow parameters for the transformation methods. However the header approach is more simpler then the approach via POs or beans. The header overwrites the configuration option "transformMethods". Example for Header Value: "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; > XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform > Methods > --- > > Key: CAMEL-9306 > URL: https://issues.apache.org/jira/browse/CAMEL-9306 > Project: Camel > Issue Type: Improvement > Components: camel-xmlsecurity >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > > In the XML Signature component you can define transform methods which are > applied to the XML document before the signature is calculated (see > configuration option "transformMethods" in the XML Signer). The definition of > these transform methods is done either via POs in the java DSL or via beans > in the Spring XML a list of such transformations. > We want to offer also the possiblity that you can specify the transformations > via the header "CamelXmlSignatureTransformMethods". The header value shall > contain a comma separated list of transformation algorithms. The header > approach will not allow parameters for the transformation methods. However > the header approach is more simpler then the approach via POs or beans. > The header overwrites the configuration option "transformMethods". > Example for Header Value: > "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9306) XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform Methods
[ https://issues.apache.org/jira/browse/CAMEL-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998511#comment-14998511 ] Franz Forsthofer commented on CAMEL-9306: - Wiki page adapted. > XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform > Methods > --- > > Key: CAMEL-9306 > URL: https://issues.apache.org/jira/browse/CAMEL-9306 > Project: Camel > Issue Type: Improvement > Components: camel-xmlsecurity >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > > In the XML Signature component you can define transform methods which are > applied to the XML document before the signature is calculated (see > configuration option "transformMethods" in the XML Signer). The definition of > these transform methods is done either via POs in the java DSL or via beans > in the Spring XML a list of such transformations. > We want to offer also the possiblity that you can specify the transformations > via the header "CamelXmlSignatureTransformMethods". The header value shall > contain a comma separated list of transformation algorithms. The header > approach will not allow parameters for the transformation methods. However > the header approach is more simpler then the approach via POs or beans. > The header overwrites the configuration option "transformMethods". > Example for Header Value: > "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-9306) XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform Methods
[ https://issues.apache.org/jira/browse/CAMEL-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer closed CAMEL-9306. --- Resolution: Fixed > XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform > Methods > --- > > Key: CAMEL-9306 > URL: https://issues.apache.org/jira/browse/CAMEL-9306 > Project: Camel > Issue Type: Improvement > Components: camel-xmlsecurity >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > > In the XML Signature component you can define transform methods which are > applied to the XML document before the signature is calculated (see > configuration option "transformMethods" in the XML Signer). The definition of > these transform methods is done either via POs in the java DSL or via beans > in the Spring XML a list of such transformations. > We want to offer also the possiblity that you can specify the transformations > via the header "CamelXmlSignatureTransformMethods". The header value shall > contain a comma separated list of transformation algorithms. The header > approach will not allow parameters for the transformation methods. However > the header approach is more simpler then the approach via POs or beans. > The header overwrites the configuration option "transformMethods". > Example for Header Value: > "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CAMEL-9306) XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform Methods
[ https://issues.apache.org/jira/browse/CAMEL-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-9306 started by Franz Forsthofer. --- > XML Signature: Header "CamelXmlSignatureTransformMethods" for Transform > Methods > --- > > Key: CAMEL-9306 > URL: https://issues.apache.org/jira/browse/CAMEL-9306 > Project: Camel > Issue Type: Improvement > Components: camel-xmlsecurity >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.17.0 > > > In the XML Signature component you can define transform methods which are > applied to the XML document before the signature is calculated (see > configuration option "transformMethods" in the XML Signer). The definition of > these transform methods is done either via POs in the java DSL or via beans > in the Spring XML a list of such transformations. > We want to offer also the possiblity that you can specify the transformations > via the header "CamelXmlSignatureTransformMethods". The header value shall > contain a comma separated list of transformation algorithms. The header > approach will not allow parameters for the transformation methods. However > the header approach is more simpler then the approach via POs or beans. > The header overwrites the configuration option "transformMethods". > Example for Header Value: > "http://www.w3.org/2000/09/xmldsig#enveloped-signature,http://www.w3.org/TR/2001/REC-xml-c14n-20010315; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-9163) PGP Data Format: Support PGP Messages without Compressed Data packet
[ https://issues.apache.org/jira/browse/CAMEL-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-9163: Description: The PGP Data format currently creates only PGP Messages with Compressed Data packet or can only decrypt/verify PGP Messages which have a Compressed Data packet. The Open PGP specification (RFC4880), however, allows also PGP Messages without a Compressed Data packet. Therefore we make the Compressed Data packet optional. We introduce the new configuration option "withCompressedDataPacket" for the marshal method which can be set to false indicating that no Compressed Data packet must be created. The unmarshal method will be able decrypting PGP Messages without a Compressed Data packet (was: The PGP Data format currently creates only PGP Messages with Compressed Data packet or can only decrypt/verify PGP Messages which have a Compressed Data packet. The Open PGP specification (RFC4880), however, allows also PGP Messages without a Compressed Data packet. Therefore we make the Compressed Data packet optional. We introduce the new configuration option "withCompressedDataPacket" for the marshal method which can be set to false indicating that no Compressed Data packet must be created. Also the unmarshal methoed will be abler to decrypt PGP Messages without a Compressed Data packet) > PGP Data Format: Support PGP Messages without Compressed Data packet > > > Key: CAMEL-9163 > URL: https://issues.apache.org/jira/browse/CAMEL-9163 > Project: Camel > Issue Type: Improvement > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.16.0 > > > The PGP Data format currently creates only PGP Messages with Compressed Data > packet or can only decrypt/verify PGP Messages which have a Compressed Data > packet. The Open PGP specification (RFC4880), however, allows also PGP > Messages without a Compressed Data packet. Therefore we make the Compressed > Data packet optional. We introduce the new configuration option > "withCompressedDataPacket" for the marshal method which can be set to false > indicating that no Compressed Data packet must be created. The unmarshal > method will be able decrypting PGP Messages without a Compressed Data packet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CAMEL-9163) PGP Data Format: Support PGP Messages without Compressed Data packet
[ https://issues.apache.org/jira/browse/CAMEL-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-9163 started by Franz Forsthofer. --- > PGP Data Format: Support PGP Messages without Compressed Data packet > > > Key: CAMEL-9163 > URL: https://issues.apache.org/jira/browse/CAMEL-9163 > Project: Camel > Issue Type: Improvement > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.16.0 > > > The PGP Data format currently creates only PGP Messages with Compressed Data > packet or can only decrypt/verify PGP Messages which have a Compressed Data > packet. The Open PGP specification (RFC4880), however, allows also PGP > Messages without a Compressed Data packet. Therefore we make the Compressed > Data packet optional. We introduce the new configuration option > "withCompressedDataPacket" for the marshal method which can be set to false > indicating that no Compressed Data packet must be created. The unmarshal > method will be able decrypting PGP Messages without a Compressed Data packet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-9163) PGP Data Format: Support PGP Messages without Compressed Data packet
Franz Forsthofer created CAMEL-9163: --- Summary: PGP Data Format: Support PGP Messages without Compressed Data packet Key: CAMEL-9163 URL: https://issues.apache.org/jira/browse/CAMEL-9163 Project: Camel Issue Type: Improvement Components: camel-crypto Reporter: Franz Forsthofer Assignee: Franz Forsthofer Fix For: 2.16.0 The PGP Data format currently creates only PGP Messages with Compressed Data packet or can only decrypt/verify PGP Messages which have a Compressed Data packet. The Open PGP specification (RFC4880), however, allows also PGP Messages without a Compressed Data packet. Therefore we make the Compressed Data packet optional. We introduce the new configuration option "withCompressedDataPacket" for the marshal method which can be set to false indicating that no Compressed Data packet must be created. Also the unmarshal methoed will be abler to decrypt PGP Messages without a Compressed Data packet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-9163) PGP Data Format: Support PGP Messages without Compressed Data packet
[ https://issues.apache.org/jira/browse/CAMEL-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14906498#comment-14906498 ] Franz Forsthofer commented on CAMEL-9163: - commit ecbbeb74f753ce81995171fb5d25f58930c22d26 wiki updated > PGP Data Format: Support PGP Messages without Compressed Data packet > > > Key: CAMEL-9163 > URL: https://issues.apache.org/jira/browse/CAMEL-9163 > Project: Camel > Issue Type: Improvement > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.16.0 > > > The PGP Data format currently creates only PGP Messages with Compressed Data > packet or can only decrypt/verify PGP Messages which have a Compressed Data > packet. The Open PGP specification (RFC4880), however, allows also PGP > Messages without a Compressed Data packet. Therefore we make the Compressed > Data packet optional. We introduce the new configuration option > "withCompressedDataPacket" for the marshal method which can be set to false > indicating that no Compressed Data packet must be created. The unmarshal > method will be able decrypting PGP Messages without a Compressed Data packet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-9163) PGP Data Format: Support PGP Messages without Compressed Data packet
[ https://issues.apache.org/jira/browse/CAMEL-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-9163. - Resolution: Fixed > PGP Data Format: Support PGP Messages without Compressed Data packet > > > Key: CAMEL-9163 > URL: https://issues.apache.org/jira/browse/CAMEL-9163 > Project: Camel > Issue Type: Improvement > Components: camel-crypto >Reporter: Franz Forsthofer >Assignee: Franz Forsthofer > Fix For: 2.16.0 > > > The PGP Data format currently creates only PGP Messages with Compressed Data > packet or can only decrypt/verify PGP Messages which have a Compressed Data > packet. The Open PGP specification (RFC4880), however, allows also PGP > Messages without a Compressed Data packet. Therefore we make the Compressed > Data packet optional. We introduce the new configuration option > "withCompressedDataPacket" for the marshal method which can be set to false > indicating that no Compressed Data packet must be created. The unmarshal > method will be able decrypting PGP Messages without a Compressed Data packet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8978) Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD
[ https://issues.apache.org/jira/browse/CAMEL-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-8978. - Resolution: Fixed Fix Version/s: (was: 2.14.4) (was: 2.15.3) I have fixed the issue only in 2.16 because there is another way described in the documentation: You can use CxfPayload.getHeaders() to set SOAP headers in the payload list. Nevertheless, with this improvement you can now also use the Camel Header. Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD Key: CAMEL-8978 URL: https://issues.apache.org/jira/browse/CAMEL-8978 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.3, 2.15.2 Reporter: Franz Forsthofer Fix For: 2.16 Attachments: 0001-Setting-SOAP-header-in-payload-case-via-camel-header.patch In the camel-cxf documentation https://camel.apache.org/cxf.html is described in the chapter How to deal with the message for a camel-cxf endpoint in PAYLOAD data format that You can use the Header.HEADER_LIST as the key to set or get the SOAP headers. But this only works for getting SOAP headers. If you want to set SOAP headers via the Camel header Header.HEADER_LIST, the headers are not taken into account in the CXF-to-endpoint. I analysed the problem and found out that - the SOAP header list is forwarded to the CXF request context - that this header list is overwritten in CxfEndpoint.CamelCxfClientImpl by the CxfPayload.getHeaders() value. My suggestion is that we merge the headers from the Camel header and the the CXF payload in CxfEndpoint.CamelCxfClientImpl. See the attached patch. With the merging we cover all different use cases: - the headers can be set in the CxfPayload - the headers can be set in the Camel header Header.list - the headers can be set in the CXFPayload and the CamelHeader Header.list. Also the case where the list instance in the CxfPayload is the same as in the Camel header (in this case no merge is necessary) is covered. This case happens if the from-endpoint is also a CXF endpoint and the CXF payload is forwarded to the to-CXF-endpoint. I can commit the change. However, before I do it I want to have the agreement from the CXF experts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8978) Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD
[ https://issues.apache.org/jira/browse/CAMEL-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14636939#comment-14636939 ] Franz Forsthofer commented on CAMEL-8978: - I updated also the wiki. Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD Key: CAMEL-8978 URL: https://issues.apache.org/jira/browse/CAMEL-8978 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.3, 2.15.2 Reporter: Franz Forsthofer Fix For: 2.16 Attachments: 0001-Setting-SOAP-header-in-payload-case-via-camel-header.patch In the camel-cxf documentation https://camel.apache.org/cxf.html is described in the chapter How to deal with the message for a camel-cxf endpoint in PAYLOAD data format that You can use the Header.HEADER_LIST as the key to set or get the SOAP headers. But this only works for getting SOAP headers. If you want to set SOAP headers via the Camel header Header.HEADER_LIST, the headers are not taken into account in the CXF-to-endpoint. I analysed the problem and found out that - the SOAP header list is forwarded to the CXF request context - that this header list is overwritten in CxfEndpoint.CamelCxfClientImpl by the CxfPayload.getHeaders() value. My suggestion is that we merge the headers from the Camel header and the the CXF payload in CxfEndpoint.CamelCxfClientImpl. See the attached patch. With the merging we cover all different use cases: - the headers can be set in the CxfPayload - the headers can be set in the Camel header Header.list - the headers can be set in the CXFPayload and the CamelHeader Header.list. Also the case where the list instance in the CxfPayload is the same as in the Camel header (in this case no merge is necessary) is covered. This case happens if the from-endpoint is also a CXF endpoint and the CXF payload is forwarded to the to-CXF-endpoint. I can commit the change. However, before I do it I want to have the agreement from the CXF experts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632297#comment-14632297
]
Franz Forsthofer commented on CAMEL-8905:
-
Sorry for not explaining this earlier in more detail:
Jackson does offer the encoding detection. However jasonpath does not call the
Jackson API with the encoding detection; jasonpath has hardcoded the UTF-8
encoding. So currently I do not think that an option to turn off the encoding
detection makes sense.
So I will go ahead without the switch.
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jsonpath-automatic-charset-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8978) Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD
Franz Forsthofer created CAMEL-8978: --- Summary: Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD Key: CAMEL-8978 URL: https://issues.apache.org/jira/browse/CAMEL-8978 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.15.2, 2.14.3 Reporter: Franz Forsthofer Fix For: 2.15.3, 2.14.4, 2.16 In the camel-cxf documentation https://camel.apache.org/cxf.html is described in the chapter How to deal with the message for a camel-cxf endpoint in PAYLOAD data format that You can use the Header.HEADER_LIST as the key to set or get the SOAP headers. But this only works for getting SOAP headers. If you want to set SOAP headers via the Camel header Header.HEADER_LIST, the headers are not taken into account in the CXF-to-endpoint. I analysed the problem and found out that - the SOAP header list is forwarded to the CXF request context - that this header list is overwritten in CxfEndpoint.CamelCxfClientImpl by the CxfPayload.getHeaders() value. My suggestion is that we merge the headers from the Camel header and the the CXF payload in CxfEndpoint.CamelCxfClientImpl. See the attached patch. With the merging we cover all different use cases: - the headers can be set in the CxfPayload - the headers can be set in the Camel header Header.list - the headers can be set in the CXFPayload and the CamelHeader Header.list. Also the case where the list instance in the CxfPayload is the same as in the Camel header (in this case no merge is necessary) is covered. This case happens if the from-endpoint is also a CXF endpoint and the CXF payload is forwarded to the to-CXF-endpoint. I can commit the change. However, before I do it I want to have the agreement from the CXF experts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8978) Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD
[ https://issues.apache.org/jira/browse/CAMEL-8978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8978: Attachment: 0001-Setting-SOAP-header-in-payload-case-via-camel-header.patch Setting of SOAP headers via the Camel Header org.apache.cxf.headers.Header.list not working for CXF data format PAYLOAD Key: CAMEL-8978 URL: https://issues.apache.org/jira/browse/CAMEL-8978 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.3, 2.15.2 Reporter: Franz Forsthofer Fix For: 2.15.3, 2.14.4, 2.16 Attachments: 0001-Setting-SOAP-header-in-payload-case-via-camel-header.patch In the camel-cxf documentation https://camel.apache.org/cxf.html is described in the chapter How to deal with the message for a camel-cxf endpoint in PAYLOAD data format that You can use the Header.HEADER_LIST as the key to set or get the SOAP headers. But this only works for getting SOAP headers. If you want to set SOAP headers via the Camel header Header.HEADER_LIST, the headers are not taken into account in the CXF-to-endpoint. I analysed the problem and found out that - the SOAP header list is forwarded to the CXF request context - that this header list is overwritten in CxfEndpoint.CamelCxfClientImpl by the CxfPayload.getHeaders() value. My suggestion is that we merge the headers from the Camel header and the the CXF payload in CxfEndpoint.CamelCxfClientImpl. See the attached patch. With the merging we cover all different use cases: - the headers can be set in the CxfPayload - the headers can be set in the Camel header Header.list - the headers can be set in the CXFPayload and the CamelHeader Header.list. Also the case where the list instance in the CxfPayload is the same as in the Camel header (in this case no merge is necessary) is covered. This case happens if the from-endpoint is also a CXF endpoint and the CXF payload is forwarded to the to-CXF-endpoint. I can commit the change. However, before I do it I want to have the agreement from the CXF experts. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14629278#comment-14629278
]
Franz Forsthofer commented on CAMEL-8905:
-
Hi Claus,
you are right, the charset determination should not be part of camel. Actually
it also should not be part of jayway/jsonpath, but be part of the used json
parser. Currently jayway/jsonpath offers to use three different parsers: gson,
jsonsmart, and jackson. Only the jackson parser offers the possibility to
determine the charset. So the right way would be to move the function to gson
and jsonsmart. But this will definitely take some time. I will try first to get
into contact with jayway/jsonpath.
Regards Franz
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jsonpath-automatic-charset-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: 0001-jsonpath-automatic-charset-detection.patch
I Improved the patch further. I have introduced the header
CamelJsonpathJsonEncoding. Here the user can specify the charset of the JSON
document. In most of the cases it is not necessary to specify the charset in
the header. If the charset is one of the unicode charsets then the charset can
be determined automatically. Or if the message body is of type String or
GenericFile with CharSet then also no charset must be specified.
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jsonpath-automatic-charset-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: (was: 0001-jasonpath-automatic-encoding-detection.patch)
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: booksUTF16BE.json, booksUTF16LE.json,
jsonUCS2BigEndianWithBOM.txt, jsonUCS2BigEndianWithoutBOM.txt,
jsonUCS2LittleEndianWithBom.txt, jsonUCS2LittleEndianWithoutBOM.txt,
jsonUTF32BEWithBOM.txt, jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt,
jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: (was: 0001-jasonpath-automatic-encoding-detection.patch)
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14605749#comment-14605749
]
Franz Forsthofer commented on CAMEL-8905:
-
The IP clearance is fine. The code is just an implementation of the encoding
part of spec RFC 4627.
But I am wondering if it is really a good idea to restrict the encoding of JSON
documents to unicode as specified in RFC 4627. There is another specification
of JSON:
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf. In
this spec no encoding is mentioned.
Instead of automatically determining the charset from the Json document, one
could get the endcoding via the method
org.apache.camel.util.IOHelper.getCharSetName(Exchange)which determines the
encoding from the message header Exchange.CHARSET_NAME or the exchange property
Exchange.CHARSET_NAME. But with this solution the header or property must be
set somehow.
What is your opinion on this?
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: 0001-jasonpath-automatic-encoding-detection.patch
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: (was: 0001-jasonpath-automatic-encoding-detection.patch)
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: booksUTF16BE.json, booksUTF16LE.json,
jsonUCS2BigEndianWithBOM.txt, jsonUCS2BigEndianWithoutBOM.txt,
jsonUCS2LittleEndianWithBom.txt, jsonUCS2LittleEndianWithoutBOM.txt,
jsonUTF32BEWithBOM.txt, jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt,
jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: 0001-jasonpath-automatic-encoding-detection.patch
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: jsonUTF32LEWithoutBOM.txt
jsonUTF32LEWithBOM.txt
jsonUTF32BEWithoutBOM.txt
jsonUTF32BEWithBOM.txt
jsonUCS2LittleEndianWithoutBOM.txt
jsonUCS2LittleEndianWithBom.txt
jsonUCS2BigEndianWithoutBOM.txt
jsonUCS2BigEndianWithBOM.txt
booksUTF16LE.json
booksUTF16BE.json
I attache the test files whose encodings are different from UTF-8 because they
are not part of the patch.
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch,
booksUTF16BE.json, booksUTF16LE.json, jsonUCS2BigEndianWithBOM.txt,
jsonUCS2BigEndianWithoutBOM.txt, jsonUCS2LittleEndianWithBom.txt,
jsonUCS2LittleEndianWithoutBOM.txt, jsonUTF32BEWithBOM.txt,
jsonUTF32BEWithoutBOM.txt, jsonUTF32LEWithBOM.txt, jsonUTF32LEWithoutBOM.txt
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: 0001-jasonpath-automatic-encoding-detection.patch
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
} else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
} else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
} else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-8905) encoding problems in jsonpath
Franz Forsthofer created CAMEL-8905:
---
Summary: encoding problems in jsonpath
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
} else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
} else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose encoding
is different from UTF-8, then jsonPath still parses the document with UTF-8.
Error location in JsonPathEngine:
} else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody who
is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the actual
commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: 0001-jasonpath-automatic-encoding-detection.patch
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Attachment: (was: 0001-jasonpath-automatic-encoding-detection.patch)
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose
encoding is different from UTF-8, then jsonPath still parses the document
with UTF-8. Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody
who is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the
actual commit or I will discard the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-8905) encoding problems in jsonpath
[
https://issues.apache.org/jira/browse/CAMEL-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Franz Forsthofer updated CAMEL-8905:
Description:
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose encoding
is different from UTF-8, then jsonPath still parses the document with UTF-8.
Error location in JsonPathEngine:
else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
}
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody who
is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the actual
commit or I will discard the patch.
was:
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
} else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
} else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
path.read(file, configuration) uses always UTF-8
- if jsonpath is called with an URL pointing to a JSON document whose encoding
is different from UTF-8, then jsonPath still parses the document with UTF-8.
Error location in JsonPathEngine:
} else if (json instanceof URL) {
URL url = (URL) json;
return path.read(url, configuration);
path.read(url, configuration) uses UTF-8
My solution proposal is to determine the encoding of the JSON documents
automatically according to the specification RFC-4627
(https://www.ietf.org/rfc/rfc4627.txt; see chapter 3. Encoding) and then call
the method path.read(jsonDocument,foundEncoding,configuration) with the found
encoding. See attached patch.
Actually I can commit the patch myself. However, I would like that somebody who
is more familiar with jsonpath than I does review my patch.
So please tell me if my patch can be accepted or not. I can then do the actual
commit or I will discard the patch.
encoding problems in jsonpath
-
Key: CAMEL-8905
URL: https://issues.apache.org/jira/browse/CAMEL-8905
Project: Camel
Issue Type: Bug
Components: camel-jsonpath
Affects Versions: 2.15.2
Reporter: Franz Forsthofer
Fix For: 2.16.0, 2.15.3
Attachments: 0001-jasonpath-automatic-encoding-detection.patch
I detected three different encoding problems in jsonpath:
- if jsonpath is called with an input stream which has an encoding different
from the default encoding (given by Charset.defaultCharset()) then jsonpath
still uses the default encoding. Error location in JsonPathEngine:
else if (json instanceof InputStream) {
InputStream is = (InputStream) json;
return path.read(is, Charset.defaultCharset().displayName(),
configuration);}
- if jsonpath is called with a json file whose encoding is different from
UTF-8, then jsonpath still parses the document with UTF-8. Error location in
JsonPathEngine:
else if (json instanceof File) {
File file = (File) json;
return path.read(file, configuration);
}
[jira] [Work started] (CAMEL-8810) Camel CXF may propagate wrong Content-Length headers
[ https://issues.apache.org/jira/browse/CAMEL-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-8810 started by Franz Forsthofer. --- Camel CXF may propagate wrong Content-Length headers Key: CAMEL-8810 URL: https://issues.apache.org/jira/browse/CAMEL-8810 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.2, 2.15.2, 2.16.0 Reporter: Stephan Siano Assignee: Franz Forsthofer Priority: Minor Attachments: 0001-CAMEL-8810-Camel-CXF-may-propagate-wrong-Content-Len.patch In some rare cases camel-cxf may propagate wrong Content-Length HTTP headers in routing scenarios. The scenario in question is a simple camel-cxf to camel-cxf scenario with a request-reply pattern. If the called server does respond with a Content-Length (not chunked) and the server does not send any HTTP protocol header that is not filtered (like Content-Length or Content-Type) the headers from the original server response are forwarded. If the payload returned by Camel is longer than the payload returned by the called server (which provided the Content-Length) e.g. because the proxy is working in PAYLOAD mode and the server uses shorter namespace prefixes for the SOAP envelope, the Content-Length will be too short and the calling client may cut off the message. See the attached unit test for details. The reason for that is that the original headers get set when copying the invocation context from the camel exchange. Normally the protocol header map will be overwritten with the map of filtered headers, so this is not an issue, however of the map of filtered headers is completely empty this will not happen. The fix is to remove the copied protocol headers in that case. The situation will rarely occur in real life because the Server header is there most of the time, so the list of filtered protocol headers is not empty. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-8810) Camel CXF may propagate wrong Content-Length headers
[ https://issues.apache.org/jira/browse/CAMEL-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer resolved CAMEL-8810. - Resolution: Fixed Camel CXF may propagate wrong Content-Length headers Key: CAMEL-8810 URL: https://issues.apache.org/jira/browse/CAMEL-8810 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.2, 2.15.2, 2.16.0 Reporter: Stephan Siano Assignee: Franz Forsthofer Priority: Minor Fix For: 2.16.0, 2.15.3, 2.14.4 Attachments: 0001-CAMEL-8810-Camel-CXF-may-propagate-wrong-Content-Len.patch In some rare cases camel-cxf may propagate wrong Content-Length HTTP headers in routing scenarios. The scenario in question is a simple camel-cxf to camel-cxf scenario with a request-reply pattern. If the called server does respond with a Content-Length (not chunked) and the server does not send any HTTP protocol header that is not filtered (like Content-Length or Content-Type) the headers from the original server response are forwarded. If the payload returned by Camel is longer than the payload returned by the called server (which provided the Content-Length) e.g. because the proxy is working in PAYLOAD mode and the server uses shorter namespace prefixes for the SOAP envelope, the Content-Length will be too short and the calling client may cut off the message. See the attached unit test for details. The reason for that is that the original headers get set when copying the invocation context from the camel exchange. Normally the protocol header map will be overwritten with the map of filtered headers, so this is not an issue, however of the map of filtered headers is completely empty this will not happen. The fix is to remove the copied protocol headers in that case. The situation will rarely occur in real life because the Server header is there most of the time, so the list of filtered protocol headers is not empty. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8810) Camel CXF may propagate wrong Content-Length headers
[ https://issues.apache.org/jira/browse/CAMEL-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8810: Fix Version/s: 2.14.4 2.15.3 2.16.0 Patch from Stephan applied to 2.16.0, 2.15.3, and 2.14.4. Thanks to Stephan Siano. Camel CXF may propagate wrong Content-Length headers Key: CAMEL-8810 URL: https://issues.apache.org/jira/browse/CAMEL-8810 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.2, 2.15.2, 2.16.0 Reporter: Stephan Siano Assignee: Franz Forsthofer Priority: Minor Fix For: 2.16.0, 2.15.3, 2.14.4 Attachments: 0001-CAMEL-8810-Camel-CXF-may-propagate-wrong-Content-Len.patch In some rare cases camel-cxf may propagate wrong Content-Length HTTP headers in routing scenarios. The scenario in question is a simple camel-cxf to camel-cxf scenario with a request-reply pattern. If the called server does respond with a Content-Length (not chunked) and the server does not send any HTTP protocol header that is not filtered (like Content-Length or Content-Type) the headers from the original server response are forwarded. If the payload returned by Camel is longer than the payload returned by the called server (which provided the Content-Length) e.g. because the proxy is working in PAYLOAD mode and the server uses shorter namespace prefixes for the SOAP envelope, the Content-Length will be too short and the calling client may cut off the message. See the attached unit test for details. The reason for that is that the original headers get set when copying the invocation context from the camel exchange. Normally the protocol header map will be overwritten with the map of filtered headers, so this is not an issue, however of the map of filtered headers is completely empty this will not happen. The fix is to remove the copied protocol headers in that case. The situation will rarely occur in real life because the Server header is there most of the time, so the list of filtered protocol headers is not empty. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-8810) Camel CXF may propagate wrong Content-Length headers
[ https://issues.apache.org/jira/browse/CAMEL-8810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer reassigned CAMEL-8810: --- Assignee: Franz Forsthofer Camel CXF may propagate wrong Content-Length headers Key: CAMEL-8810 URL: https://issues.apache.org/jira/browse/CAMEL-8810 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.14.2, 2.15.2, 2.16.0 Reporter: Stephan Siano Assignee: Franz Forsthofer Priority: Minor Attachments: 0001-CAMEL-8810-Camel-CXF-may-propagate-wrong-Content-Len.patch In some rare cases camel-cxf may propagate wrong Content-Length HTTP headers in routing scenarios. The scenario in question is a simple camel-cxf to camel-cxf scenario with a request-reply pattern. If the called server does respond with a Content-Length (not chunked) and the server does not send any HTTP protocol header that is not filtered (like Content-Length or Content-Type) the headers from the original server response are forwarded. If the payload returned by Camel is longer than the payload returned by the called server (which provided the Content-Length) e.g. because the proxy is working in PAYLOAD mode and the server uses shorter namespace prefixes for the SOAP envelope, the Content-Length will be too short and the calling client may cut off the message. See the attached unit test for details. The reason for that is that the original headers get set when copying the invocation context from the camel exchange. Normally the protocol header map will be overwritten with the map of filtered headers, so this is not an issue, however of the map of filtered headers is completely empty this will not happen. The fix is to remove the copied protocol headers in that case. The situation will rarely occur in real life because the Server header is there most of the time, so the list of filtered protocol headers is not empty. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8688) Removed StreamCache when doing a Wiretap
[ https://issues.apache.org/jira/browse/CAMEL-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523004#comment-14523004 ] Franz Forsthofer commented on CAMEL-8688: - Hi, I am working on a patch. Regards Franz Removed StreamCache when doing a Wiretap Key: CAMEL-8688 URL: https://issues.apache.org/jira/browse/CAMEL-8688 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1 Reporter: Geert Vanheusden Attachments: WireTapTest.java Hi, I noticed a bug where the body (StreamCache) was already removed before the exchange reached the end (in the Wiretap route). I added a test as an attachment. f you run the test you can clearly see the temp file deletion followed by the closed stream exception: Tried 1 to delete file: /var/folders/db/brq60fqj4vb8mnx_5nlz36nwgn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp with result: true Cannot reset stream from file /var/folders/db/brq60fqj4vb8mnx_5nlz36nwgn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp I encountered the same issue during a more complex route that does some splitting (zip file) and multicasting. This occurred on Camel 2.14.1 so it could be fixed by https://issues.apache.org/jira/browse/CAMEL-8284 but I need to test this. Kind regards, Geert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8688) Removed StreamCache when doing a Wiretap
[ https://issues.apache.org/jira/browse/CAMEL-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8688: Attachment: 0001-wire-tap-streaming-problem-camel-netty-http.patch 0001-wire-tap-streaming-problem-camel-core.patch Hi, Here is the patch. It consists of two files. One for camel-core and one for camel-netty-http. I had to change the clone() method in the interface StreamCache to StreamCache clone(Exchange exchange) because I needed to count the exchanges which are relevant for the cached file. Regards Franz Forsthofer SAP SE e-mail: franz.forstho...@sap.com Removed StreamCache when doing a Wiretap Key: CAMEL-8688 URL: https://issues.apache.org/jira/browse/CAMEL-8688 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1 Reporter: Geert Vanheusden Attachments: 0001-wire-tap-streaming-problem-camel-core.patch, 0001-wire-tap-streaming-problem-camel-netty-http.patch, WireTapTest.java Hi, I noticed a bug where the body (StreamCache) was already removed before the exchange reached the end (in the Wiretap route). I added a test as an attachment. f you run the test you can clearly see the temp file deletion followed by the closed stream exception: Tried 1 to delete file: /var/folders/db/brq60fqj4vb8mnx_5nlz36nwgn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp with result: true Cannot reset stream from file /var/folders/db/brq60fqj4vb8mnx_5nlz36nwgn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp I encountered the same issue during a more complex route that does some splitting (zip file) and multicasting. This occurred on Camel 2.14.1 so it could be fixed by https://issues.apache.org/jira/browse/CAMEL-8284 but I need to test this. Kind regards, Geert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8688) Removed StreamCache when doing a Wiretap
[ https://issues.apache.org/jira/browse/CAMEL-8688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8688: Attachment: (was: 0001-wire-tap-streaming-problem-camel-netty-http.patch) Removed StreamCache when doing a Wiretap Key: CAMEL-8688 URL: https://issues.apache.org/jira/browse/CAMEL-8688 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.15.1 Reporter: Geert Vanheusden Attachments: 0001-wire-tap-streaming-problem-camel-core.patch, WireTapTest.java Hi, I noticed a bug where the body (StreamCache) was already removed before the exchange reached the end (in the Wiretap route). I added a test as an attachment. f you run the test you can clearly see the temp file deletion followed by the closed stream exception: Tried 1 to delete file: /var/folders/db/brq60fqj4vb8mnx_5nlz36nwgn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp with result: true Cannot reset stream from file /var/folders/db/brq60fqj4vb8mnx_5nlz36nwgn/T/camel/camel-tmp-00cd1ce2-7d44-47fe-b357-008e8146f770/cos8797132745923044996.tmp I encountered the same issue during a more complex route that does some splitting (zip file) and multicasting. This occurred on Camel 2.14.1 so it could be fixed by https://issues.apache.org/jira/browse/CAMEL-8284 but I need to test this. Kind regards, Geert -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316333#comment-14316333 ] Franz Forsthofer commented on CAMEL-8284: - Hello Claus, I attached an alternative solution 0001-parallel-processable-stream.patch where I do not change the StreamCache interface but where I introduce a new interface ParallelProcessableStream with a copy method. With this solution, implementations of StreamCache must not be changed. Please have a look, if this solution can be applied for 2.14 and 2.15. The above patch does not make changes in the netty component (as suggested by Stephan Siano, see patch 0001-CAMEL-8284-Implement-copy-method-in-NettyChannelBuff.patch) because the implementation of ParallelProcessableStream is optional for enabling parallel processing. But of course it would make sense to implement the ParallelProcessableStream in NettyChannelBufferStreamCache. Regards Franz MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: Future Attachments: 0001-CAMEL-8284-Implement-copy-method-in-NettyChannelBuff.patch, 0001-multicast-with-parallel-processing-and-stream-cachin.patch, 0001-parallel-processable-stream.patch If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8284: Attachment: 0001-parallel-processable-stream.patch MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: Future Attachments: 0001-CAMEL-8284-Implement-copy-method-in-NettyChannelBuff.patch, 0001-multicast-with-parallel-processing-and-stream-cachin.patch, 0001-parallel-processable-stream.patch If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8336) XML Signature: XAdES: Wrong value for attribute Qualifier of element CommitmentTypeId
[ https://issues.apache.org/jira/browse/CAMEL-8336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8336: Attachment: 0001-xades-CommitmentTypeIdQualifier-corrected.patch XML Signature: XAdES: Wrong value for attribute Qualifier of element CommitmentTypeId --- Key: CAMEL-8336 URL: https://issues.apache.org/jira/browse/CAMEL-8336 Project: Camel Issue Type: Bug Components: camel-xmlsecurity Affects Versions: 2.15.0 Reporter: Franz Forsthofer Fix For: 2.15.0 Attachments: 0001-xades-CommitmentTypeIdQualifier-corrected.patch If you specify in the XAdES Properties a value of the attribute attribute Qualifier of the element CommitmentTypeId then this value is not used, instead wrongly the value of the DataObjectFormatIdentifierQualifier is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-8336) XML Signature: XAdES: Wrong value for attribute Qualifier of element CommitmentTypeId
Franz Forsthofer created CAMEL-8336: --- Summary: XML Signature: XAdES: Wrong value for attribute Qualifier of element CommitmentTypeId Key: CAMEL-8336 URL: https://issues.apache.org/jira/browse/CAMEL-8336 Project: Camel Issue Type: Bug Components: camel-xmlsecurity Affects Versions: 2.15.0 Reporter: Franz Forsthofer Fix For: 2.15.0 If you specify in the XAdES Properties a value of the attribute attribute Qualifier of the element CommitmentTypeId then this value is not used, instead wrongly the value of the DataObjectFormatIdentifierQualifier is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8284: Attachment: (was: 0001-multicast-with-parallel-processing-and-stream-cachin.patch) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: Future If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8284: Attachment: 0001-multicast-with-parallel-processing-and-stream-cachin.patch MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: Future Attachments: 0001-multicast-with-parallel-processing-and-stream-cachin.patch If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8284: Attachment: 0001-multicast-with-parallel-processing-and-stream-cachin.patch I changed the patch again in order to make it less intrusive. Please check. MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: Future Attachments: 0001-multicast-with-parallel-processing-and-stream-cachin.patch If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8284: Attachment: (was: 0001-multicast-with-parallel-processing-and-stream-cachin.patch) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: Future If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-8284) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results
[ https://issues.apache.org/jira/browse/CAMEL-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Franz Forsthofer updated CAMEL-8284: Attachment: (was: 0001-multicast-with-parallel-processing-and-stream-cachin.patch) MultiCast in Parallel Processing Mode with StreamCache leads to wrong results - Key: CAMEL-8284 URL: https://issues.apache.org/jira/browse/CAMEL-8284 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.14.1 Reporter: Franz Forsthofer Fix For: 2.14.2, 2.15.0 If the multi-cast processor gets as an input a stream cache in the parallel processing mode, then the stream is read by different threads concurrently. This leads to wrong results. The attached patch solves this issue. The idea of the patch is to provide a copy of the stream cache to each thread. The copy will use the same cache of the original stream cache, only the stream which accesses the cached data will be a separate instance. For this, we introduced the new method copy() in the StreamCache class. See also discussion in http://camel.465427.n5.nabble.com/Data-Corruption-in-SFTP-in-Parallel-Multicast-branches-td5761673.html#a5761781 Franz Forsthofer SAP SE e-mail: franz.forsthofer[at]sap.com -- This message was sent by Atlassian JIRA (v6.3.4#6332)
