[jira] [Created] (CAMEL-19794) OsgiEventAdminNotifier not getting registered
Stephan Siano created CAMEL-19794:
-
Summary: OsgiEventAdminNotifier not getting registered
Key: CAMEL-19794
URL: https://issues.apache.org/jira/browse/CAMEL-19794
Project: Camel
Issue Type: Bug
Components: camel-blueprint
Affects Versions: 3.21.0, 3.14.9
Reporter: Stephan Siano
Assignee: Grzegorz Grzybek
After an update from Camel 2.x to Camel 3.14.7 we noticed that the
OsgiEventAdminNotifier is not getting registered in Camel 3 blueprint contexts
(the same issue exists in all newer Camel 3 versions).
The reason for this is in the following code in
org.apache.camel.blueprint.CamelContextFactoryBean:
{code}
try {
getClass().getClassLoader().loadClass("org.osgi.service.event.EventAdmin");
getContext().getManagementStrategy().addEventNotifier(new
OsgiEventAdminNotifier(bundleContext));
} catch (Throwable t) {
// Ignore, if the EventAdmin package is not available, just don't
// use it
LOG.debug("EventAdmin package is not available, just don't use it");
}
{code}
The problem is that the camel-osgi-core bundle (where the class
OsgiEventAdminNotifier is located) has an optional import for
org.osgi.service.event, but the camel-blueprint bundle where the
CamelContextFactoryBean is located does not have this import.
I see two solutions for the issue:
either add the line
org.osgi.service.event;resolution:=optional,
to camel.osgi.import in the camel-blueprint pom
or change the above code to use the classloader of the camel-osgi-core bundle
to load the EventAdmin class in the code above:
{code}
OsgiEventAdminNotifier.class.getClassLoader().loadClass("org.osgi.service.event.EventAdmin");
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18130) camel-ftp - Move-File Post Processing in (S)FTP not working if OutMessage is set
[ https://issues.apache.org/jira/browse/CAMEL-18130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539560#comment-17539560 ] Stephan Siano commented on CAMEL-18130: --- Hi Claus, sure out messages are deprecated, but several standard camel components (e.g. camel-cxf) still use out messages, so this issue will happen if one of these components is involved. > camel-ftp - Move-File Post Processing in (S)FTP not working if OutMessage is > set > > > Key: CAMEL-18130 > URL: https://issues.apache.org/jira/browse/CAMEL-18130 > Project: Camel > Issue Type: Bug > Components: camel-file >Affects Versions: 3.17.0 >Reporter: Manuel Shenavai >Priority: Minor > > When the last processor of a route sets a outMessage, the move-file post > processing in (s)ftp adapter is not working. > > I created following reproducer: [https://github.com/mash-sap/camelFTP] The > evaluation of the expressions (i.e. file:onlyname) is looking in the > inMessage of the exchange to evaluate the filename > (link<[https://github.com/apache/camel/blob/main/core/camel-core-languages/src/main/java/org/apache/camel/language/simple/SimpleExpressionBuilder.java#L259]>). > However, the properties of the files may get bound to the outMessage if > there is one > (link<[https://github.com/apache/camel/blob/camel-2.24.x/camel-core/src/main/java/org/apache/camel/component/file/GenericFile.java#L134]>). > Therefore the evaluation is not working as expected. I'm not too familiar > with the code, but one possible solution (for post-processing) could be, to > always bind the file-properties to the in message. But maybe this is not > valid for other use-cases and therefore parameterization is required: > Link<[https://github.com/apache/camel/blob/camel-2.24.x/camel-core/src/main/java/org/apache/camel/component/file/GenericFile.java#L134]> -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (CAMEL-17957) camel-cxf - OSGi import range too restrictive
[ https://issues.apache.org/jira/browse/CAMEL-17957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-17957. --- Resolution: Fixed > camel-cxf - OSGi import range too restrictive > - > > Key: CAMEL-17957 > URL: https://issues.apache.org/jira/browse/CAMEL-17957 > Project: Camel > Issue Type: Task > Components: came-cxf, karaf, osgi >Affects Versions: 3.14.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Major > Fix For: 3.11.7, 3.14.3, 3.17.0 > > > The camel-cxf and camel-cxf transport bundles do not wire with CXF 3.4.5 in > Camel 3.14.2 on a Karaf 4.3.6 container (the latest version). > The error is: > Unsatisfied Requirements: > [org.apache.camel.camel-cxf-transport [161](R 161.0)] osgi.wiring.package; > (&(osgi.wiring.package=org.apache.cxf)(version>=3.4.0)(version<=3.4.0)) > [org.apache.camel.camel-cxf-transport [161](R 161.0)] > ... > The problem is the import range for the CXF bundles of [3.4,3.4]. The karaf > container will interpret that as "exactly version 3.4.0" so this will wire > with CXF 3.4.0 but nothing else. I think what is mean here is to have any CXF > 3.4 version, but then the import range should be [3.4,3.5) instead (this > means the version has to be greater or equal 3.4.0 and smaller than 3.5.0). > If I manually change that in the bundle manifests, wiring with CXF 3.4.5 > works. > The issue was introduced with CAMEL-17137, so it should all branches where > thich change was applied. > The fix for this is to change the cxf-version-range property in parent/pom.xml > from > [3.5,3.5] > to > [3.5,3.6) > and from > [3.4,3.4] > to > [3.4,3.5) > in the different branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17957) camel-cxf - OSGi import range too restrictive
[ https://issues.apache.org/jira/browse/CAMEL-17957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521554#comment-17521554 ] Stephan Siano commented on CAMEL-17957: --- added to main, 3.14.x and 3.11.x > camel-cxf - OSGi import range too restrictive > - > > Key: CAMEL-17957 > URL: https://issues.apache.org/jira/browse/CAMEL-17957 > Project: Camel > Issue Type: Task > Components: came-cxf, karaf, osgi >Affects Versions: 3.14.2 >Reporter: Stephan Siano >Priority: Major > Fix For: 3.11.7, 3.14.3, 3.17.0 > > > The camel-cxf and camel-cxf transport bundles do not wire with CXF 3.4.5 in > Camel 3.14.2 on a Karaf 4.3.6 container (the latest version). > The error is: > Unsatisfied Requirements: > [org.apache.camel.camel-cxf-transport [161](R 161.0)] osgi.wiring.package; > (&(osgi.wiring.package=org.apache.cxf)(version>=3.4.0)(version<=3.4.0)) > [org.apache.camel.camel-cxf-transport [161](R 161.0)] > ... > The problem is the import range for the CXF bundles of [3.4,3.4]. The karaf > container will interpret that as "exactly version 3.4.0" so this will wire > with CXF 3.4.0 but nothing else. I think what is mean here is to have any CXF > 3.4 version, but then the import range should be [3.4,3.5) instead (this > means the version has to be greater or equal 3.4.0 and smaller than 3.5.0). > If I manually change that in the bundle manifests, wiring with CXF 3.4.5 > works. > The issue was introduced with CAMEL-17137, so it should all branches where > thich change was applied. > The fix for this is to change the cxf-version-range property in parent/pom.xml > from > [3.5,3.5] > to > [3.5,3.6) > and from > [3.4,3.4] > to > [3.4,3.5) > in the different branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (CAMEL-17957) camel-cxf - OSGi import range too restrictive
[ https://issues.apache.org/jira/browse/CAMEL-17957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-17957: - Assignee: Stephan Siano > camel-cxf - OSGi import range too restrictive > - > > Key: CAMEL-17957 > URL: https://issues.apache.org/jira/browse/CAMEL-17957 > Project: Camel > Issue Type: Task > Components: came-cxf, karaf, osgi >Affects Versions: 3.14.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Major > Fix For: 3.11.7, 3.14.3, 3.17.0 > > > The camel-cxf and camel-cxf transport bundles do not wire with CXF 3.4.5 in > Camel 3.14.2 on a Karaf 4.3.6 container (the latest version). > The error is: > Unsatisfied Requirements: > [org.apache.camel.camel-cxf-transport [161](R 161.0)] osgi.wiring.package; > (&(osgi.wiring.package=org.apache.cxf)(version>=3.4.0)(version<=3.4.0)) > [org.apache.camel.camel-cxf-transport [161](R 161.0)] > ... > The problem is the import range for the CXF bundles of [3.4,3.4]. The karaf > container will interpret that as "exactly version 3.4.0" so this will wire > with CXF 3.4.0 but nothing else. I think what is mean here is to have any CXF > 3.4 version, but then the import range should be [3.4,3.5) instead (this > means the version has to be greater or equal 3.4.0 and smaller than 3.5.0). > If I manually change that in the bundle manifests, wiring with CXF 3.4.5 > works. > The issue was introduced with CAMEL-17137, so it should all branches where > thich change was applied. > The fix for this is to change the cxf-version-range property in parent/pom.xml > from > [3.5,3.5] > to > [3.5,3.6) > and from > [3.4,3.4] > to > [3.4,3.5) > in the different branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CAMEL-17957) camel-cxf - OSGi import range too restrictive
[ https://issues.apache.org/jira/browse/CAMEL-17957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521518#comment-17521518 ] Stephan Siano commented on CAMEL-17957: --- I will do the changes for these branches if it is ok for you. > camel-cxf - OSGi import range too restrictive > - > > Key: CAMEL-17957 > URL: https://issues.apache.org/jira/browse/CAMEL-17957 > Project: Camel > Issue Type: Task > Components: came-cxf, karaf, osgi >Affects Versions: 3.14.2 >Reporter: Stephan Siano >Priority: Major > Fix For: 3.11.7, 3.14.3, 3.17.0 > > > The camel-cxf and camel-cxf transport bundles do not wire with CXF 3.4.5 in > Camel 3.14.2 on a Karaf 4.3.6 container (the latest version). > The error is: > Unsatisfied Requirements: > [org.apache.camel.camel-cxf-transport [161](R 161.0)] osgi.wiring.package; > (&(osgi.wiring.package=org.apache.cxf)(version>=3.4.0)(version<=3.4.0)) > [org.apache.camel.camel-cxf-transport [161](R 161.0)] > ... > The problem is the import range for the CXF bundles of [3.4,3.4]. The karaf > container will interpret that as "exactly version 3.4.0" so this will wire > with CXF 3.4.0 but nothing else. I think what is mean here is to have any CXF > 3.4 version, but then the import range should be [3.4,3.5) instead (this > means the version has to be greater or equal 3.4.0 and smaller than 3.5.0). > If I manually change that in the bundle manifests, wiring with CXF 3.4.5 > works. > The issue was introduced with CAMEL-17137, so it should all branches where > thich change was applied. > The fix for this is to change the cxf-version-range property in parent/pom.xml > from > [3.5,3.5] > to > [3.5,3.6) > and from > [3.4,3.4] > to > [3.4,3.5) > in the different branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (CAMEL-17957) CXF import range too restrictive in OSGi
Stephan Siano created CAMEL-17957: - Summary: CXF import range too restrictive in OSGi Key: CAMEL-17957 URL: https://issues.apache.org/jira/browse/CAMEL-17957 Project: Camel Issue Type: Bug Components: came-cxf, karaf, osgi Affects Versions: 3.14.2 Reporter: Stephan Siano The camel-cxf and camel-cxf transport bundles do not wire with CXF 3.4.5 in Camel 3.14.2 on a Karaf 4.3.6 container (the latest version). The error is: Unsatisfied Requirements: [org.apache.camel.camel-cxf-transport [161](R 161.0)] osgi.wiring.package; (&(osgi.wiring.package=org.apache.cxf)(version>=3.4.0)(version<=3.4.0)) [org.apache.camel.camel-cxf-transport [161](R 161.0)] ... The problem is the import range for the CXF bundles of [3.4,3.4]. The karaf container will interpret that as "exactly version 3.4.0" so this will wire with CXF 3.4.0 but nothing else. I think what is mean here is to have any CXF 3.4 version, but then the import range should be [3.4,3.5) instead (this means the version has to be greater or equal 3.4.0 and smaller than 3.5.0). If I manually change that in the bundle manifests, wiring with CXF 3.4.5 works. The issue was introduced with CAMEL-17137, so it should all branches where thich change was applied. The fix for this is to change the cxf-version-range property in parent/pom.xml from [3.5,3.5] to [3.5,3.6) and from [3.4,3.4] to [3.4,3.5) in the different branches. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (CAMEL-14072) FileInputStreamCache will not delete temporary file if file system is full
[ https://issues.apache.org/jira/browse/CAMEL-14072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-14072: -- Fix Version/s: 2.25.0 3.0.0 2.24.3 > FileInputStreamCache will not delete temporary file if file system is full > -- > > Key: CAMEL-14072 > URL: https://issues.apache.org/jira/browse/CAMEL-14072 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 2.24.2, 3.0.0.RC2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.24.3, 3.0.0, 2.25.0 > > > If a FileInputStreamCache completely fills up the underlying fileystem > (before the cache file is completely written) processing fails and the > temporary file is not deleted afterwards. > The error as such is of course unavoidable but the temporary file should be > deleted afterwards. > The reason for this issue is that trying to close the FileOutputStream will > throw an IOException (no space left on device). As a consequence the coding > that tries to delete the file is not called. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14072) FileInputStreamCache will not delete temporary file if file system is full
[ https://issues.apache.org/jira/browse/CAMEL-14072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-14072. --- Resolution: Fixed > FileInputStreamCache will not delete temporary file if file system is full > -- > > Key: CAMEL-14072 > URL: https://issues.apache.org/jira/browse/CAMEL-14072 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 2.24.2, 3.0.0.RC2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.24.3, 3.0.0, 2.25.0 > > > If a FileInputStreamCache completely fills up the underlying fileystem > (before the cache file is completely written) processing fails and the > temporary file is not deleted afterwards. > The error as such is of course unavoidable but the temporary file should be > deleted afterwards. > The reason for this issue is that trying to close the FileOutputStream will > throw an IOException (no space left on device). As a consequence the coding > that tries to delete the file is not called. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14072) FileInputStreamCache will not delete temporary file if file system is full
Stephan Siano created CAMEL-14072: - Summary: FileInputStreamCache will not delete temporary file if file system is full Key: CAMEL-14072 URL: https://issues.apache.org/jira/browse/CAMEL-14072 Project: Camel Issue Type: Bug Components: came-core Affects Versions: 3.0.0.RC2, 2.24.2 Reporter: Stephan Siano Assignee: Stephan Siano If a FileInputStreamCache completely fills up the underlying fileystem (before the cache file is completely written) processing fails and the temporary file is not deleted afterwards. The error as such is of course unavoidable but the temporary file should be deleted afterwards. The reason for this issue is that trying to close the FileOutputStream will throw an IOException (no space left on device). As a consequence the coding that tries to delete the file is not called. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CAMEL-14058) NullPointerException for failed One-Way requests with HTTP session handling
[ https://issues.apache.org/jira/browse/CAMEL-14058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-14058. --- Resolution: Fixed > NullPointerException for failed One-Way requests with HTTP session handling > --- > > Key: CAMEL-14058 > URL: https://issues.apache.org/jira/browse/CAMEL-14058 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.24.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Trivial > Fix For: 2.24.3, 3.0.0, 2.25.0 > > > In some cases there is no inMessage in the cxf exchange in case of an error. > If HTTP session handling is enabled (cookies), this will result in a > NullPointerException. > The fix for this is rather trivial; a null check has to be done before > accessing the inMessage. > This usually happens for one-way messages where HTTP session handling does > not make much sense (because without a response there are no cookies), but > nevertheless there should be no NullPointerException -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CAMEL-14058) NullPointerException for failed One-Way requests with HTTP session handling
[ https://issues.apache.org/jira/browse/CAMEL-14058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-14058: -- Fix Version/s: 2.25.0 3.0.0 2.24.3 > NullPointerException for failed One-Way requests with HTTP session handling > --- > > Key: CAMEL-14058 > URL: https://issues.apache.org/jira/browse/CAMEL-14058 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.24.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Trivial > Fix For: 2.24.3, 3.0.0, 2.25.0 > > > In some cases there is no inMessage in the cxf exchange in case of an error. > If HTTP session handling is enabled (cookies), this will result in a > NullPointerException. > The fix for this is rather trivial; a null check has to be done before > accessing the inMessage. > This usually happens for one-way messages where HTTP session handling does > not make much sense (because without a response there are no cookies), but > nevertheless there should be no NullPointerException -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CAMEL-14058) NullPointerException for failed One-Way requests with HTTP session handling
Stephan Siano created CAMEL-14058: - Summary: NullPointerException for failed One-Way requests with HTTP session handling Key: CAMEL-14058 URL: https://issues.apache.org/jira/browse/CAMEL-14058 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.24.2 Reporter: Stephan Siano Assignee: Stephan Siano In some cases there is no inMessage in the cxf exchange in case of an error. If HTTP session handling is enabled (cookies), this will result in a NullPointerException. The fix for this is rather trivial; a null check has to be done before accessing the inMessage. This usually happens for one-way messages where HTTP session handling does not make much sense (because without a response there are no cookies), but nevertheless there should be no NullPointerException -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837202#comment-16837202 ] Stephan Siano commented on CAMEL-13497: --- Great, Thanks for your help! > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.3, 2.24.1 > > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837197#comment-16837197 ] Stephan Siano commented on CAMEL-13497: --- Oh, Sorry I overlooked that. Which branch does this need to go into, camel-2.x? > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.3, 2.24.1 > > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13497: -- Fix Version/s: 2.23.3 2.24.0 3.0.0 > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.24.0, 2.23.3 > > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-13497. --- Resolution: Fixed > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.3, 2.24.1 > > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13497: -- Fix Version/s: (was: 2.24.0) 2.24.1 > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.3, 2.24.1 > > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13497: -- Fix Version/s: (was: 2.24.1) 2.24.0 > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.24.0, 2.23.3 > > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
[ https://issues.apache.org/jira/browse/CAMEL-13497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13497: -- Priority: Minor (was: Major) > Setting a clientConfig parameter always creates new cookie store per endpoint > - > > Key: CAMEL-13497 > URL: https://issues.apache.org/jira/browse/CAMEL-13497 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.23.2 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If a clientConfig parameter is defined for an ahc endpoint, a new cookie > store will be created on the endpoint, regardless of the configuration set to > the clientConfig parameter. > This makes it impossible to have an endpoint without a cookie store, when > this parameter is set (which also means that the clientConfig parameter and > the cookieHandler paramter do not work together). > The root cause for this issue is that AhcComponent.cloneConfig() is called at > several places in the code to create a configuration builder from the > provided configuration. This method is calling new > DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new > builder, but this call will create a new cookie store on each invocation and > provide it to the new builder. This means even if the cookie store is set to > null in the provided configuration the client for the endpoint will be > created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13497) Setting a clientConfig parameter always creates new cookie store per endpoint
Stephan Siano created CAMEL-13497: - Summary: Setting a clientConfig parameter always creates new cookie store per endpoint Key: CAMEL-13497 URL: https://issues.apache.org/jira/browse/CAMEL-13497 Project: Camel Issue Type: Bug Components: camel-ahc Affects Versions: 2.23.2 Reporter: Stephan Siano Assignee: Stephan Siano If a clientConfig parameter is defined for an ahc endpoint, a new cookie store will be created on the endpoint, regardless of the configuration set to the clientConfig parameter. This makes it impossible to have an endpoint without a cookie store, when this parameter is set (which also means that the clientConfig parameter and the cookieHandler paramter do not work together). The root cause for this issue is that AhcComponent.cloneConfig() is called at several places in the code to create a configuration builder from the provided configuration. This method is calling new DefaultAsyncHttpClientConfig.Builder(clientConfig), to create that new builder, but this call will create a new cookie store on each invocation and provide it to the new builder. This means even if the cookie store is set to null in the provided configuration the client for the endpoint will be created with a cloned configuration, which will then have a new cookie store. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13168) Underlying File for StreamCache gets deleted too early with direct-vm
[ https://issues.apache.org/jira/browse/CAMEL-13168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-13168. --- Resolution: Fixed > Underlying File for StreamCache gets deleted too early with direct-vm > - > > Key: CAMEL-13168 > URL: https://issues.apache.org/jira/browse/CAMEL-13168 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.2, 2.24.0, 2.22.4 > > > If one route calls a different route via direct-vm endpoint and the second > route creates a StreamCache based for a file in the called route but the > payload is propagated back to the calling route, this route will not be able > to call the file because it is already deleted. > The issue is actually the same as for CAMEL-7787. As the multicast processor > the direct-vm processor creates a copy of the exchange and does perform the > further processing with this exchange till the route comes back. The stream > cache will create a synchronization on this second exchange to delete the > file when the exchange is done, but the StreamCache as an entity (then > without underlying file) might be handed back to the original exchange. > The fix is actually the same as for CAMEL-7787, set the exchange property > Exchange.STREAM_CACHE_UNIT_OF_WORK to the LUW of the initial exchange. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13168) Underlying File for StreamCache gets deleted too early with direct-vm
[ https://issues.apache.org/jira/browse/CAMEL-13168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13168: -- Fix Version/s: 2.22.4 2.24.0 2.23.2 3.0.0 > Underlying File for StreamCache gets deleted too early with direct-vm > - > > Key: CAMEL-13168 > URL: https://issues.apache.org/jira/browse/CAMEL-13168 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.2, 2.24.0, 2.22.4 > > > If one route calls a different route via direct-vm endpoint and the second > route creates a StreamCache based for a file in the called route but the > payload is propagated back to the calling route, this route will not be able > to call the file because it is already deleted. > The issue is actually the same as for CAMEL-7787. As the multicast processor > the direct-vm processor creates a copy of the exchange and does perform the > further processing with this exchange till the route comes back. The stream > cache will create a synchronization on this second exchange to delete the > file when the exchange is done, but the StreamCache as an entity (then > without underlying file) might be handed back to the original exchange. > The fix is actually the same as for CAMEL-7787, set the exchange property > Exchange.STREAM_CACHE_UNIT_OF_WORK to the LUW of the initial exchange. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13168) Underlying File for StreamCache gets deleted too early with direct-vm
[ https://issues.apache.org/jira/browse/CAMEL-13168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16762648#comment-16762648 ] Stephan Siano commented on CAMEL-13168: --- Yes, I am working on it. Can the tests in core/camel-core use direct-vm endpoints or do I have to move the test for that? > Underlying File for StreamCache gets deleted too early with direct-vm > - > > Key: CAMEL-13168 > URL: https://issues.apache.org/jira/browse/CAMEL-13168 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If one route calls a different route via direct-vm endpoint and the second > route creates a StreamCache based for a file in the called route but the > payload is propagated back to the calling route, this route will not be able > to call the file because it is already deleted. > The issue is actually the same as for CAMEL-7787. As the multicast processor > the direct-vm processor creates a copy of the exchange and does perform the > further processing with this exchange till the route comes back. The stream > cache will create a synchronization on this second exchange to delete the > file when the exchange is done, but the StreamCache as an entity (then > without underlying file) might be handed back to the original exchange. > The fix is actually the same as for CAMEL-7787, set the exchange property > Exchange.STREAM_CACHE_UNIT_OF_WORK to the LUW of the initial exchange. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (CAMEL-13168) Underlying File for StreamCache gets deleted too early with direct-vm
[ https://issues.apache.org/jira/browse/CAMEL-13168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-13168 started by Stephan Siano. - > Underlying File for StreamCache gets deleted too early with direct-vm > - > > Key: CAMEL-13168 > URL: https://issues.apache.org/jira/browse/CAMEL-13168 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If one route calls a different route via direct-vm endpoint and the second > route creates a StreamCache based for a file in the called route but the > payload is propagated back to the calling route, this route will not be able > to call the file because it is already deleted. > The issue is actually the same as for CAMEL-7787. As the multicast processor > the direct-vm processor creates a copy of the exchange and does perform the > further processing with this exchange till the route comes back. The stream > cache will create a synchronization on this second exchange to delete the > file when the exchange is done, but the StreamCache as an entity (then > without underlying file) might be handed back to the original exchange. > The fix is actually the same as for CAMEL-7787, set the exchange property > Exchange.STREAM_CACHE_UNIT_OF_WORK to the LUW of the initial exchange. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13168) Underlying File for StreamCache gets deleted too early with direct-vm
Stephan Siano created CAMEL-13168: - Summary: Underlying File for StreamCache gets deleted too early with direct-vm Key: CAMEL-13168 URL: https://issues.apache.org/jira/browse/CAMEL-13168 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.23.1 Reporter: Stephan Siano Assignee: Stephan Siano If one route calls a different route via direct-vm endpoint and the second route creates a StreamCache based for a file in the called route but the payload is propagated back to the calling route, this route will not be able to call the file because it is already deleted. The issue is actually the same as for CAMEL-7787. As the multicast processor the direct-vm processor creates a copy of the exchange and does perform the further processing with this exchange till the route comes back. The stream cache will create a synchronization on this second exchange to delete the file when the exchange is done, but the StreamCache as an entity (then without underlying file) might be handed back to the original exchange. The fix is actually the same as for CAMEL-7787, set the exchange property Exchange.STREAM_CACHE_UNIT_OF_WORK to the LUW of the initial exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-13114. --- Resolution: Fixed > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.22.3, 3.0.0, 2.23.2, 2.24.0 > > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. > Most servers (like the jetty server used in the junit tests) also accept the > format with multiple cookie headers, but some don't. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13114: -- Fix Version/s: 2.22.3 > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.22.3, 3.0.0, 2.23.2, 2.24.0 > > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. > Most servers (like the jetty server used in the junit tests) also accept the > format with multiple cookie headers, but some don't. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13114: -- Fix Version/s: 2.23.2 > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.23.2, 2.24.0 > > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. > Most servers (like the jetty server used in the junit tests) also accept the > format with multiple cookie headers, but some don't. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750031#comment-16750031 ] Stephan Siano commented on CAMEL-13114: --- Yes, I am working on it, it just takes time to check out the respective branch, build it and run the tests... > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. > Most servers (like the jetty server used in the junit tests) also accept the > format with multiple cookie headers, but some don't. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13114: -- Fix Version/s: 2.24.0 3.0.0 > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 3.0.0, 2.24.0 > > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. > Most servers (like the jetty server used in the junit tests) also accept the > format with multiple cookie headers, but some don't. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13114) Provide single Cookie header for multiple cookies
Stephan Siano created CAMEL-13114: - Summary: Provide single Cookie header for multiple cookies Key: CAMEL-13114 URL: https://issues.apache.org/jira/browse/CAMEL-13114 Project: Camel Issue Type: Improvement Components: camel-ahc Affects Versions: 2.23.1 Reporter: Stephan Siano Assignee: Stephan Siano If a cookieHandler is defined on a camel AHC component and multiple cookies are stored for the server, the AHC component will send out multiple headers named Cookie which each have one value. According to RFC 2965 one header should be sent out as a semicolon separated list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13114: -- Description: If a cookieHandler is defined on a camel AHC component and multiple cookies are stored for the server, the AHC component will send out multiple headers named Cookie which each have one value. According to RFC 2965 one header should be sent out as a semicolon separated list. Most servers (like the jetty server used in the junit tests) also accept the format with multiple cookie headers, but some don't. was: If a cookieHandler is defined on a camel AHC component and multiple cookies are stored for the server, the AHC component will send out multiple headers named Cookie which each have one value. According to RFC 2965 one header should be sent out as a semicolon separated list. > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. > Most servers (like the jetty server used in the junit tests) also accept the > format with multiple cookie headers, but some don't. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-13114) Provide single Cookie header for multiple cookies
[ https://issues.apache.org/jira/browse/CAMEL-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-13114: -- Priority: Minor (was: Major) > Provide single Cookie header for multiple cookies > - > > Key: CAMEL-13114 > URL: https://issues.apache.org/jira/browse/CAMEL-13114 > Project: Camel > Issue Type: Improvement > Components: camel-ahc >Affects Versions: 2.23.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If a cookieHandler is defined on a camel AHC component and multiple cookies > are stored for the server, the AHC component will send out multiple headers > named Cookie which each have one value. > According to RFC 2965 one header should be sent out as a semicolon separated > list. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-13024) Camel-Mail breaks some attachment names with many special characters
Stephan Siano created CAMEL-13024:
-
Summary: Camel-Mail breaks some attachment names with many special
characters
Key: CAMEL-13024
URL: https://issues.apache.org/jira/browse/CAMEL-13024
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.23.0
Reporter: Stephan Siano
Attachments: MailBindingAttachmentEncodedFilenameTest.java
The patch for CAMEL-12630 introduced the following line for Attachment file
names in the MailBinding class.
{code:java}
String fileName = FileUtil.stripPath(part.getFileName());{code}
This code usually makes sense, it strips paths from attachment names. However,
if the file name of the attachment contains many non-ASCII characters (more
than ASCII characters) the file name provided by the mail is Base64 encoded,
e.g.: "=?UTF-8?B?6Kq/5pW0?="
As the / is a valid character in Base64 encoding (but is not a path delimiter
there) the stripPath() call on that string will mutilate the filename to
"5pW0?=".
A workaround for this issue is to set the Java system property
"mail.mime.decodefilename" to "true". In this case the part.getFileName() will
decode the filename before stripping paths.
The attached unit test might demonstrate the issue.
I am not sure how this can be fixed in a compatible way. One option would be to
perform a MimeUtility.decodeText() call on the file name (if it is not null),
which will essentially have the same effect as setting the system property
(which means that the attachment filename is decoded before processing it
further), but this will be kind of incompatible.
Note: The issue will not occur if there are more ASCII characters than
non-ASCII characters in the filename, because in that case the non-ASCII
characters will be encoded using quoted printable encoding (which does not
include a "/" character), and even if the file name is Base64 encoded it does
not necessarily mean that the Base64 encoded filename contains a "/", so you
might hardly see that issue in real life.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12227) camel-ahc - Upgrade to 2.3.0 version
[ https://issues.apache.org/jira/browse/CAMEL-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-12227: -- Fix Version/s: (was: Future) 2.21.0 > camel-ahc - Upgrade to 2.3.0 version > > > Key: CAMEL-12227 > URL: https://issues.apache.org/jira/browse/CAMEL-12227 > Project: Camel > Issue Type: Task > Components: camel-ahc >Reporter: Claus Ibsen >Assignee: Stephan Siano >Priority: Major > Fix For: 2.21.0 > > > We need to upgrade from 2.0.x to 2.1.x. > There is some API breakings so the source code needs to be updated. > Contributions is welcome -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12227) camel-ahc - Upgrade to 2.3.0 version
[ https://issues.apache.org/jira/browse/CAMEL-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-12227. --- Resolution: Fixed > camel-ahc - Upgrade to 2.3.0 version > > > Key: CAMEL-12227 > URL: https://issues.apache.org/jira/browse/CAMEL-12227 > Project: Camel > Issue Type: Task > Components: camel-ahc >Reporter: Claus Ibsen >Assignee: Stephan Siano >Priority: Major > Fix For: 2.21.0 > > > We need to upgrade from 2.0.x to 2.1.x. > There is some API breakings so the source code needs to be updated. > Contributions is welcome -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12227) camel-ahc - Upgrade to 2.3.0 version
[ https://issues.apache.org/jira/browse/CAMEL-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-12227: -- Summary: camel-ahc - Upgrade to 2.3.0 version (was: camel-ahc - Upgrade to 2.1.x version) > camel-ahc - Upgrade to 2.3.0 version > > > Key: CAMEL-12227 > URL: https://issues.apache.org/jira/browse/CAMEL-12227 > Project: Camel > Issue Type: Task > Components: camel-ahc >Reporter: Claus Ibsen >Assignee: Stephan Siano >Priority: Major > Fix For: Future > > > We need to upgrade from 2.0.x to 2.1.x. > There is some API breakings so the source code needs to be updated. > Contributions is welcome -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CAMEL-12227) camel-ahc - Upgrade to 2.1.x version
[ https://issues.apache.org/jira/browse/CAMEL-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-12227: - Assignee: Stephan Siano > camel-ahc - Upgrade to 2.1.x version > > > Key: CAMEL-12227 > URL: https://issues.apache.org/jira/browse/CAMEL-12227 > Project: Camel > Issue Type: Task > Components: camel-ahc >Reporter: Claus Ibsen >Assignee: Stephan Siano >Priority: Major > Fix For: Future > > > We need to upgrade from 2.0.x to 2.1.x. > There is some API breakings so the source code needs to be updated. > Contributions is welcome -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12227) camel-ahc - Upgrade to 2.1.x version
[ https://issues.apache.org/jira/browse/CAMEL-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1638#comment-1638 ] Stephan Siano commented on CAMEL-12227: --- Don't get me wrong, I am willing to do that, I just wanted to clarify the boundary conditions for it. So, if I get this correctly I will change the ahc version reference property in the parent pom to 2.2.1 (or 2.3.0?), adapt the cookie handling till the tests work and then do a commit to the master branch for it. Is there anything else I need to take care of (e.g. some netty reference)? > camel-ahc - Upgrade to 2.1.x version > > > Key: CAMEL-12227 > URL: https://issues.apache.org/jira/browse/CAMEL-12227 > Project: Camel > Issue Type: Task > Components: camel-ahc >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > We need to upgrade from 2.0.x to 2.1.x. > There is some API breakings so the source code needs to be updated. > Contributions is welcome -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12227) camel-ahc - Upgrade to 2.1.x version
[ https://issues.apache.org/jira/browse/CAMEL-12227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16355522#comment-16355522 ] Stephan Siano commented on CAMEL-12227: --- I can have a look. What do I need to do to test this (and how do we sync the changes)? > camel-ahc - Upgrade to 2.1.x version > > > Key: CAMEL-12227 > URL: https://issues.apache.org/jira/browse/CAMEL-12227 > Project: Camel > Issue Type: Task > Components: camel-ahc >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > We need to upgrade from 2.0.x to 2.1.x. > There is some API breakings so the source code needs to be updated. > Contributions is welcome -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12008) Add type converter from byte array to java.io.Reader
[
https://issues.apache.org/jira/browse/CAMEL-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16251522#comment-16251522
]
Stephan Siano commented on CAMEL-12008:
---
Hi Andrea,
Oh sorry, I forgot that.
Best regards
Stephan
> Add type converter from byte array to java.io.Reader
>
>
> Key: CAMEL-12008
> URL: https://issues.apache.org/jira/browse/CAMEL-12008
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Markus Muenkel
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.21.0
>
> Attachments: diff.txt
>
>
> The class {{org.apache.camel.converter.IOConverter}} supports type conversion
> from {{java.io.InputStream}} to {{java.io.Reader}}, but conversion from
> {{byte[]}} to {{java.io.Reader}} is not yet supported. In this improvement we
> would like to close this gap by adding a corresponding type conversion method
> to {{org.apache.camel.converter.IOConverter}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-12008) Add type converter from byte array to java.io.Reader
[
https://issues.apache.org/jira/browse/CAMEL-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-12008:
--
Priority: Minor (was: Major)
> Add type converter from byte array to java.io.Reader
>
>
> Key: CAMEL-12008
> URL: https://issues.apache.org/jira/browse/CAMEL-12008
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Markus Muenkel
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.21.0
>
> Attachments: diff.txt
>
>
> The class {{org.apache.camel.converter.IOConverter}} supports type conversion
> from {{java.io.InputStream}} to {{java.io.Reader}}, but conversion from
> {{byte[]}} to {{java.io.Reader}} is not yet supported. In this improvement we
> would like to close this gap by adding a corresponding type conversion method
> to {{org.apache.camel.converter.IOConverter}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-12008) Add type converter from byte array to java.io.Reader
[
https://issues.apache.org/jira/browse/CAMEL-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano resolved CAMEL-12008.
---
Resolution: Fixed
> Add type converter from byte array to java.io.Reader
>
>
> Key: CAMEL-12008
> URL: https://issues.apache.org/jira/browse/CAMEL-12008
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Markus Muenkel
>Assignee: Stephan Siano
> Fix For: 2.21.0
>
> Attachments: diff.txt
>
>
> The class {{org.apache.camel.converter.IOConverter}} supports type conversion
> from {{java.io.InputStream}} to {{java.io.Reader}}, but conversion from
> {{byte[]}} to {{java.io.Reader}} is not yet supported. In this improvement we
> would like to close this gap by adding a corresponding type conversion method
> to {{org.apache.camel.converter.IOConverter}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-12008) Add type converter from byte array to java.io.Reader
[
https://issues.apache.org/jira/browse/CAMEL-12008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano reassigned CAMEL-12008:
-
Assignee: Stephan Siano
> Add type converter from byte array to java.io.Reader
>
>
> Key: CAMEL-12008
> URL: https://issues.apache.org/jira/browse/CAMEL-12008
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Reporter: Markus Muenkel
>Assignee: Stephan Siano
> Fix For: 2.21.0
>
> Attachments: diff.txt
>
>
> The class {{org.apache.camel.converter.IOConverter}} supports type conversion
> from {{java.io.InputStream}} to {{java.io.Reader}}, but conversion from
> {{byte[]}} to {{java.io.Reader}} is not yet supported. In this improvement we
> would like to close this gap by adding a corresponding type conversion method
> to {{org.apache.camel.converter.IOConverter}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (CAMEL-11662) camel-ahc does not support multi-value HTTP headers properly
[
https://issues.apache.org/jira/browse/CAMEL-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano closed CAMEL-11662.
-
Resolution: Won't Fix
> camel-ahc does not support multi-value HTTP headers properly
>
>
> Key: CAMEL-11662
> URL: https://issues.apache.org/jira/browse/CAMEL-11662
> Project: Camel
> Issue Type: Bug
> Components: camel-ahc
>Affects Versions: 2.19.1
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.20.0
>
>
> The camel-ahc component does not support multi-value HTTP headers properly.
> If the camel message contains a header with a list value the list is
> converted into a String before setting it to a header, which is not the
> proper format for a multi-value http header.
> Example: If the camel header named "to" has a value of type List,
> which contains the elements "foo" and "bar" the generated HTTP header named
> "to" will have the value "[foo, bar]"
> According to RFC 7230 section 3.2.2 this is the wrong format. There should be
> a single line generated from it, but the list should simply be comma
> separated ("foo, bar" without the square brackets).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CAMEL-11662) camel-ahc does not support multi-value HTTP headers properly
[
https://issues.apache.org/jira/browse/CAMEL-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121668#comment-16121668
]
Stephan Siano commented on CAMEL-11662:
---
On a second thought the current behaviour is implemented across all HTTP
components in Camel. Having multiple HTTP headers with one name is forbidden by
RFC 7230 (except for well known exceptions like the Set-Cookie header).
The RFC also states that "a recipient MAY combine multiple header fields with
the same field name into one "field-name: field-value" pair, without changing
the semantics of the message, by appending each subsequent field value to the
combined field value in order, separated by a comma.
>From that perspective it might be an idea to use the list semantic without the
>sqare brackets in camel, but that would break compatibility, so we'd probably
>leave everything as it is.
> camel-ahc does not support multi-value HTTP headers properly
>
>
> Key: CAMEL-11662
> URL: https://issues.apache.org/jira/browse/CAMEL-11662
> Project: Camel
> Issue Type: Bug
> Components: camel-ahc
>Affects Versions: 2.19.1
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.20.0
>
>
> The camel-ahc component does not support multi-value HTTP headers properly.
> If the camel message contains a header with a list value the list is
> converted into a String before setting it to a header, which is not the
> proper format for a multi-value http header.
> Example: If the camel header named "to" has a value of type List,
> which contains the elements "foo" and "bar" the generated HTTP header named
> "to" will have the value "[foo, bar]"
> According to RFC 7230 section 3.2.2 this is the wrong format. There should be
> a single line generated from it, but the list should simply be comma
> separated ("foo, bar" without the square brackets).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CAMEL-11662) camel-ahc does not support multi-value HTTP headers properly
[
https://issues.apache.org/jira/browse/CAMEL-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-11662:
--
Description:
The camel-ahc component does not support multi-value HTTP headers properly.
If the camel message contains a header with a list value the list is converted
into a String before setting it to a header, which is not the proper format for
a multi-value http header.
Example: If the camel header named "to" has a value of type List, which
contains the elements "foo" and "bar" the generated HTTP header named "to" will
have the value "[foo, bar]"
According to RFC 7230 section 3.2.2 this is the wrong format. There should be a
single line generated from it, but the list should simply be comma separated
("foo, bar" without the square brackets).
was:
The camel-ahc component does not support multi-value HTTP headers properly.
If the camel message contains a header with a list value the list is converted
into a String before setting it to a header, which is not the proper format for
a multi-value http header.
Example: If the camel header named "to" has a value of type List, which
contains the elements "foo" and "bar" the generated HTTP header named "to" will
have the value "[ foo, bar]"
According to RFC 7230 section 3.2.2 this is the wrong format. There should be a
single line generated from it, but the list should simply be comma separated
("foo,bar" without the square brackets).
> camel-ahc does not support multi-value HTTP headers properly
>
>
> Key: CAMEL-11662
> URL: https://issues.apache.org/jira/browse/CAMEL-11662
> Project: Camel
> Issue Type: Bug
> Components: camel-ahc
>Affects Versions: 2.19.1
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.20.0
>
>
> The camel-ahc component does not support multi-value HTTP headers properly.
> If the camel message contains a header with a list value the list is
> converted into a String before setting it to a header, which is not the
> proper format for a multi-value http header.
> Example: If the camel header named "to" has a value of type List,
> which contains the elements "foo" and "bar" the generated HTTP header named
> "to" will have the value "[foo, bar]"
> According to RFC 7230 section 3.2.2 this is the wrong format. There should be
> a single line generated from it, but the list should simply be comma
> separated ("foo, bar" without the square brackets).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11662) camel-ahc does not support multi-value HTTP headers properly
[
https://issues.apache.org/jira/browse/CAMEL-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano reassigned CAMEL-11662:
-
Assignee: Stephan Siano
> camel-ahc does not support multi-value HTTP headers properly
>
>
> Key: CAMEL-11662
> URL: https://issues.apache.org/jira/browse/CAMEL-11662
> Project: Camel
> Issue Type: Bug
> Components: camel-ahc
>Affects Versions: 2.19.1
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.20.0
>
>
> The camel-ahc component does not support multi-value HTTP headers properly.
> If the camel message contains a header with a list value the list is
> converted into a String before setting it to a header, which is not the
> proper format for a multi-value http header.
> Example: If the camel header named "to" has a value of type List,
> which contains the elements "foo" and "bar" the generated HTTP header named
> "to" will have the value "[ foo, bar]"
> According to RFC 7230 section 3.2.2 this is the wrong format. There should be
> a single line generated from it, but the list should simply be comma
> separated ("foo,bar" without the square brackets).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CAMEL-11662) camel-ahc does not support multi-value HTTP headers properly
[
https://issues.apache.org/jira/browse/CAMEL-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano reassigned CAMEL-11662:
-
Assignee: (was: Stephan Siano)
> camel-ahc does not support multi-value HTTP headers properly
>
>
> Key: CAMEL-11662
> URL: https://issues.apache.org/jira/browse/CAMEL-11662
> Project: Camel
> Issue Type: Bug
> Components: camel-ahc
>Affects Versions: 2.19.1
>Reporter: Stephan Siano
>Priority: Minor
> Fix For: 2.20.0
>
>
> The camel-ahc component does not support multi-value HTTP headers properly.
> If the camel message contains a header with a list value the list is
> converted into a String before setting it to a header, which is not the
> proper format for a multi-value http header.
> Example: If the camel header named "to" has a value of type List,
> which contains the elements "foo" and "bar" the generated HTTP header named
> "to" will have the value "[ foo, bar]"
> According to RFC 7230 section 3.2.2 this is the wrong format. There should be
> a single line generated from it, but the list should simply be comma
> separated ("foo,bar" without the square brackets).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CAMEL-11662) camel-ahc does not support multi-value HTTP headers properly
Stephan Siano created CAMEL-11662:
-
Summary: camel-ahc does not support multi-value HTTP headers
properly
Key: CAMEL-11662
URL: https://issues.apache.org/jira/browse/CAMEL-11662
Project: Camel
Issue Type: Bug
Components: camel-ahc
Affects Versions: 2.19.1
Reporter: Stephan Siano
Assignee: Stephan Siano
Priority: Minor
Fix For: 2.20.0
The camel-ahc component does not support multi-value HTTP headers properly.
If the camel message contains a header with a list value the list is converted
into a String before setting it to a header, which is not the proper format for
a multi-value http header.
Example: If the camel header named "to" has a value of type List, which
contains the elements "foo" and "bar" the generated HTTP header named "to" will
have the value "[ foo, bar]"
According to RFC 7230 section 3.2.2 this is the wrong format. There should be a
single line generated from it, but the list should simply be comma separated
("foo,bar" without the square brackets).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-11649. --- Resolution: Fixed > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.20.0, 2.19.3 > > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-11649 started by Stephan Siano. - > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.20.0, 2.19.3 > > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118173#comment-16118173 ] Stephan Siano commented on CAMEL-11649: --- I have pushed the change to master, I will cherry-pick it to camel-2.19.x once the 2.19.2 release is done. > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.20.0, 2.19.3 > > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-11649: -- Fix Version/s: 2.20.0 > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.20.0, 2.19.3 > > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-11649: -- Affects Version/s: 2.19.1 > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.19.3 > > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-11649: -- Fix Version/s: 2.19.3 > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.19.3 > > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-11649: -- Description: The cookie handling as implemented with CAMEL-10392 only works for a single cookie sent from the server as the handling of multi-valued headers is wrong > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > The cookie handling as implemented with CAMEL-10392 only works for a single > cookie sent from the server as the handling of multi-valued headers is wrong -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11649) Cookie Handling only works for one cookie
[ https://issues.apache.org/jira/browse/CAMEL-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-11649: - Assignee: Stephan Siano > Cookie Handling only works for one cookie > - > > Key: CAMEL-11649 > URL: https://issues.apache.org/jira/browse/CAMEL-11649 > Project: Camel > Issue Type: Bug > Components: camel-ahc >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11649) Cookie Handling only works for one cookie
Stephan Siano created CAMEL-11649: - Summary: Cookie Handling only works for one cookie Key: CAMEL-11649 URL: https://issues.apache.org/jira/browse/CAMEL-11649 Project: Camel Issue Type: Bug Components: camel-ahc Reporter: Stephan Siano Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-11568) Allow to set a CookiePolicy to CookieHandler
[ https://issues.apache.org/jira/browse/CAMEL-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-11568. --- Resolution: Fixed > Allow to set a CookiePolicy to CookieHandler > > > Key: CAMEL-11568 > URL: https://issues.apache.org/jira/browse/CAMEL-11568 > Project: Camel > Issue Type: Improvement > Components: camel-http-common >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Trivial > Fix For: 2.20.0 > > > In some cases it might be useful to define a CookiePolicy for the > CookieHandler implementations included in camel-http-common. This will allow > some control over the cookies that can be stored by a server. See the JDK > javadoc for details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11568) Allow to set a CookiePolicy to CookieHandler
[ https://issues.apache.org/jira/browse/CAMEL-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-11568: - Assignee: Stephan Siano > Allow to set a CookiePolicy to CookieHandler > > > Key: CAMEL-11568 > URL: https://issues.apache.org/jira/browse/CAMEL-11568 > Project: Camel > Issue Type: Improvement > Components: camel-http-common >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Trivial > Fix For: 2.20.0 > > > In some cases it might be useful to define a CookiePolicy for the > CookieHandler implementations included in camel-http-common. This will allow > some control over the cookies that can be stored by a server. See the JDK > javadoc for details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11568) Allow to set a CookiePolicy to CookieHandler
Stephan Siano created CAMEL-11568: - Summary: Allow to set a CookiePolicy to CookieHandler Key: CAMEL-11568 URL: https://issues.apache.org/jira/browse/CAMEL-11568 Project: Camel Issue Type: Improvement Components: camel-http-common Affects Versions: 2.19.1 Reporter: Stephan Siano Priority: Trivial Fix For: 2.20.0 In some cases it might be useful to define a CookiePolicy for the CookieHandler implementations included in camel-http-common. This will allow some control over the cookies that can be stored by a server. See the JDK javadoc for details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CAMEL-11486) NullPointerException for invalid payload with session handling enabled
[ https://issues.apache.org/jira/browse/CAMEL-11486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-11486. --- Resolution: Fixed > NullPointerException for invalid payload with session handling enabled > -- > > Key: CAMEL-11486 > URL: https://issues.apache.org/jira/browse/CAMEL-11486 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Trivial > Fix For: 2.19.2, 2.20.0 > > > If HTTP session handling is enabled for a CXF producer endpoint and an > invalid payload is provided to the endpoint a NullPointerException is thrown > instead of an Illegal state exception. > This fix is just to add a null check to the inMessage of the CXF exchange. > This will only affect the thrown exception not actual message processing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (CAMEL-11486) NullPointerException for invalid payload with session handling enabled
[ https://issues.apache.org/jira/browse/CAMEL-11486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-11486: - Assignee: Stephan Siano > NullPointerException for invalid payload with session handling enabled > -- > > Key: CAMEL-11486 > URL: https://issues.apache.org/jira/browse/CAMEL-11486 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.19.1 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Trivial > Fix For: 2.19.2, 2.20.0 > > > If HTTP session handling is enabled for a CXF producer endpoint and an > invalid payload is provided to the endpoint a NullPointerException is thrown > instead of an Illegal state exception. > This fix is just to add a null check to the inMessage of the CXF exchange. > This will only affect the thrown exception not actual message processing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CAMEL-11486) NullPointerException for invalid payload with session handling enabled
Stephan Siano created CAMEL-11486: - Summary: NullPointerException for invalid payload with session handling enabled Key: CAMEL-11486 URL: https://issues.apache.org/jira/browse/CAMEL-11486 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.19.1 Reporter: Stephan Siano Priority: Trivial Fix For: 2.19.2, 2.20.0 If HTTP session handling is enabled for a CXF producer endpoint and an invalid payload is provided to the endpoint a NullPointerException is thrown instead of an Illegal state exception. This fix is just to add a null check to the inMessage of the CXF exchange. This will only affect the thrown exception not actual message processing. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CAMEL-8419) Camel StreamCache does not work with CXF consumer for InOut messages
[ https://issues.apache.org/jira/browse/CAMEL-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16028054#comment-16028054 ] Stephan Siano commented on CAMEL-8419: -- The issue still occurs with newer versions, so yes, we should consider this. I still don't have a better idea than copying the Camel stream cache into a CXF stream cache, but maybe some CXF expert has a good idea for this. > Camel StreamCache does not work with CXF consumer for InOut messages > > > Key: CAMEL-8419 > URL: https://issues.apache.org/jira/browse/CAMEL-8419 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.14.1 >Reporter: Stephan Siano > Attachments: > 0001-CAMEL-8419-Camel-StreamCache-does-not-work-with-CXF-.patch > > > If a route that is started by a CXF consumer and has an InOut exchange > pattern (meaning that the CXF consumer is returning a response back to the > caller) contains a StreamCache as message object that is not in memory, > returning the payload will fail. > The reason for this is that an on-disk stream cache in Camel will be removed > when the LUW ends, but CXF will return the response afterwards. > See the two attached unit tests for details. > I don't like the actual patch too much, as it copies on-disk camel stream > caches into CXF stream caches when creating the CXF message object in camel > CXF, but this is about the last step before the LUW ends (and the file gets > deleted). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CAMEL-11047) STARTTLS broken with camel-mail
[
https://issues.apache.org/jira/browse/CAMEL-11047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano resolved CAMEL-11047.
---
Resolution: Fixed
Fix Version/s: 2.19.0
2.18.4
2.17.7
> STARTTLS broken with camel-mail
> ---
>
> Key: CAMEL-11047
> URL: https://issues.apache.org/jira/browse/CAMEL-11047
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.17.6, 2.18.3
>Reporter: Stephan Siano
>Assignee: Stephan Siano
> Fix For: 2.17.7, 2.18.4, 2.19.0
>
>
> A to URI like
> {noformat}
> smtp://xxx:25?mail.smtp.starttls.enable=true=#sslContextParameters
> {noformat}
> will create an exception when trying to connect to the SMTP server. The error
> message is
> {noformat}
> javax.mail.MessagingException: Could not connect to SMTP host: xxx, port: 25;
> nested exception is:
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
> connection?
> at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:2102)
> at
> com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:699)
> at javax.mail.Service.connect(Service.java:366)
> at
> org.apache.camel.component.mail.DefaultJavaMailSender.send(DefaultJavaMailSender.java:112)
> at
> org.apache.camel.component.mail.MailProducer.process(MailProducer.java:63)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> at
> org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:173)
> at
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:341)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:168)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:468)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:62)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)
> at
> org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:68)
> at
> org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:412)
> at
> org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:1)
> at
> org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:270)
> at
> org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:380)
> at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:221)
> at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:124)
> at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110)
> at
> com.sap.esb.camel.mail.endpoint.configurator.mail.impl.MailRouteSendingTest.testSendMail(MailRouteSendingTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at
[jira] [Commented] (CAMEL-11047) STARTTLS broken with camel-mail
[
https://issues.apache.org/jira/browse/CAMEL-11047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15936270#comment-15936270
]
Stephan Siano commented on CAMEL-11047:
---
unfortunately we cannot unit-test this issue. The mock-javamail implementation
we use for unit tests does not use any transport, so SSL options will have no
effect on the tests. The existing unit tests only test that a specific socket
factory is defined, not that it works.
> STARTTLS broken with camel-mail
> ---
>
> Key: CAMEL-11047
> URL: https://issues.apache.org/jira/browse/CAMEL-11047
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.17.6, 2.18.3
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>
> A to URI like
> {noformat}
> smtp://xxx:25?mail.smtp.starttls.enable=true=#sslContextParameters
> {noformat}
> will create an exception when trying to connect to the SMTP server. The error
> message is
> {noformat}
> javax.mail.MessagingException: Could not connect to SMTP host: xxx, port: 25;
> nested exception is:
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
> connection?
> at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:2102)
> at
> com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:699)
> at javax.mail.Service.connect(Service.java:366)
> at
> org.apache.camel.component.mail.DefaultJavaMailSender.send(DefaultJavaMailSender.java:112)
> at
> org.apache.camel.component.mail.MailProducer.process(MailProducer.java:63)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> at
> org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:173)
> at
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:341)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:168)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:468)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:62)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)
> at
> org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:68)
> at
> org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:412)
> at
> org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:1)
> at
> org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:270)
> at
> org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:380)
> at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:221)
> at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:124)
> at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110)
> at
> com.sap.esb.camel.mail.endpoint.configurator.mail.impl.MailRouteSendingTest.testSendMail(MailRouteSendingTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at
[jira] [Assigned] (CAMEL-11047) STARTTLS broken with camel-mail
[
https://issues.apache.org/jira/browse/CAMEL-11047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano reassigned CAMEL-11047:
-
Assignee: Stephan Siano
> STARTTLS broken with camel-mail
> ---
>
> Key: CAMEL-11047
> URL: https://issues.apache.org/jira/browse/CAMEL-11047
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.17.6, 2.18.3
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>
> A to URI like
> {noformat}
> smtp://xxx:25?mail.smtp.starttls.enable=true=#sslContextParameters
> {noformat}
> will create an exception when trying to connect to the SMTP server. The error
> message is
> {noformat}
> javax.mail.MessagingException: Could not connect to SMTP host: xxx, port: 25;
> nested exception is:
> javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
> connection?
> at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:2102)
> at
> com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:699)
> at javax.mail.Service.connect(Service.java:366)
> at
> org.apache.camel.component.mail.DefaultJavaMailSender.send(DefaultJavaMailSender.java:112)
> at
> org.apache.camel.component.mail.MailProducer.process(MailProducer.java:63)
> at
> org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
> at
> org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:173)
> at
> org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:341)
> at
> org.apache.camel.processor.SendProcessor.process(SendProcessor.java:168)
> at
> org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:468)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:62)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
> at
> org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)
> at
> org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:68)
> at
> org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:412)
> at
> org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:1)
> at
> org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:270)
> at
> org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:380)
> at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:221)
> at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:124)
> at
> org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110)
> at
> com.sap.esb.camel.mail.endpoint.configurator.mail.impl.MailRouteSendingTest.testSendMail(MailRouteSendingTest.java:36)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>
[jira] [Created] (CAMEL-11047) STARTTLS broken with camel-mail
Stephan Siano created CAMEL-11047:
-
Summary: STARTTLS broken with camel-mail
Key: CAMEL-11047
URL: https://issues.apache.org/jira/browse/CAMEL-11047
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.18.3, 2.17.6
Reporter: Stephan Siano
A to URI like
{noformat}
smtp://xxx:25?mail.smtp.starttls.enable=true=#sslContextParameters
{noformat}
will create an exception when trying to connect to the SMTP server. The error
message is
{noformat}
javax.mail.MessagingException: Could not connect to SMTP host: xxx, port: 25;
nested exception is:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
at com.sun.mail.smtp.SMTPTransport.openServer(SMTPTransport.java:2102)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:699)
at javax.mail.Service.connect(Service.java:366)
at
org.apache.camel.component.mail.DefaultJavaMailSender.send(DefaultJavaMailSender.java:112)
at
org.apache.camel.component.mail.MailProducer.process(MailProducer.java:63)
at
org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
at
org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:173)
at
org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:341)
at
org.apache.camel.processor.SendProcessor.process(SendProcessor.java:168)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:468)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
at
org.apache.camel.component.direct.DirectProducer.process(DirectProducer.java:62)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:197)
at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)
at
org.apache.camel.processor.UnitOfWorkProducer.process(UnitOfWorkProducer.java:68)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:412)
at
org.apache.camel.impl.ProducerCache$2.doInProducer(ProducerCache.java:1)
at
org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:270)
at
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:380)
at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:221)
at
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:124)
at
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:110)
at
com.sap.esb.camel.mail.endpoint.configurator.mail.impl.MailRouteSendingTest.testSendMail(MailRouteSendingTest.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
[jira] [Resolved] (CAMEL-10841) Move operation will create a warning log message
[
https://issues.apache.org/jira/browse/CAMEL-10841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano resolved CAMEL-10841.
---
Resolution: Fixed
Fix Version/s: 2.19.0
2.18.3
2.17.6
> Move operation will create a warning log message
>
>
> Key: CAMEL-10841
> URL: https://issues.apache.org/jira/browse/CAMEL-10841
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.17.5, 2.18.2
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.17.6, 2.18.3, 2.19.0
>
>
> I'm using an enpoint like this one :
> -
> sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
>
> With 2.18.2, I have logs like this :
> {noformat}
> 2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
> sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
> Cannot delete file: folder1/folder2/../archive/myfile.txt
> com.jcraft.jsch.SftpException: No such file
> at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
> at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
> at
> org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
> at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
> {noformat}
> the issue was introduced with CAMEL-10712
> Thanks to Guillaume Lundy for pointing that out
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CAMEL-10841) Move operation will create a warning log message
[
https://issues.apache.org/jira/browse/CAMEL-10841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-10841:
--
Description:
I'm using an enpoint like this one :
-
sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
With 2.18.2, I have logs like this :
{noformat}
2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
Cannot delete file: folder1/folder2/../archive/myfile.txt
com.jcraft.jsch.SftpException: No such file
at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
at
org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
{noformat}
the issue was introduced with CAMEL-10712
Thanks to Guillaume Lundy for pointing that out
was:
I'm using an enpoint like this one :
-
sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
With 2.18.2, I have logs like this :
{noformat}
2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
Cannot delete file: folder1/folder2/../archive/myfile.txt
com.jcraft.jsch.SftpException: No such file
at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
at
org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
{noformat}
the issue was introduced with CAMEL-10712
> Move operation will create a warning log message
>
>
> Key: CAMEL-10841
> URL: https://issues.apache.org/jira/browse/CAMEL-10841
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.17.5, 2.18.2
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
>
> I'm using an enpoint like this one :
> -
> sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
>
> With 2.18.2, I have logs like this :
> {noformat}
> 2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
> sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
> Cannot delete file: folder1/folder2/../archive/myfile.txt
> com.jcraft.jsch.SftpException: No such file
> at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
> at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
> at
> org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
> at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
> {noformat}
> the issue was introduced with CAMEL-10712
> Thanks to Guillaume Lundy for pointing that out
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CAMEL-10841) Move operation will create a warning log message
[
https://issues.apache.org/jira/browse/CAMEL-10841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15869631#comment-15869631
]
Stephan Siano commented on CAMEL-10841:
---
unfortunately the deleteFile calls are spread all over the camel-file and the
camel-ftp components, so changing the way exceptions are thrown for this issue
is not reasonable.
I will just reduce the log level for the log to debug. This will normally not
fill up the log with confusing entries, but will make it possible to analyze
issues if they occur. Other similar issues (e.g. when creating directories) are
also logged with debug in the file component.
> Move operation will create a warning log message
>
>
> Key: CAMEL-10841
> URL: https://issues.apache.org/jira/browse/CAMEL-10841
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.17.5, 2.18.2
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
>
> I'm using an enpoint like this one :
> -
> sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
>
> With 2.18.2, I have logs like this :
> {noformat}
> 2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
> sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
> Cannot delete file: folder1/folder2/../archive/myfile.txt
> com.jcraft.jsch.SftpException: No such file
> at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
> at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
> at
> org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
> at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
> {noformat}
> the issue was introduced with CAMEL-10712
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CAMEL-10841) Move operation will create a warning log message
[
https://issues.apache.org/jira/browse/CAMEL-10841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-10841:
--
Description:
I'm using an enpoint like this one :
-
sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
With 2.18.2, I have logs like this :
{noformat}
2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
Cannot delete file: folder1/folder2/../archive/myfile.txt
com.jcraft.jsch.SftpException: No such file
at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
at
org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
{noformat}
the issue was introduced with CAMEL-10712
was:
I'm using an enpoint like this one :
-
sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
With 2.18.2, I have logs like this :
{noformat}
2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
Cannot delete file: folder1/folder2/../archive/myfile.txt
com.jcraft.jsch.SftpException: No such file
at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
at
org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
{noformat}
> Move operation will create a warning log message
>
>
> Key: CAMEL-10841
> URL: https://issues.apache.org/jira/browse/CAMEL-10841
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.18.2
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
>
> I'm using an enpoint like this one :
> -
> sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
>
> With 2.18.2, I have logs like this :
> {noformat}
> 2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
> sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
> Cannot delete file: folder1/folder2/../archive/myfile.txt
> com.jcraft.jsch.SftpException: No such file
> at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
> at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
> at
> org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
> at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
> {noformat}
> the issue was introduced with CAMEL-10712
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CAMEL-10841) Move operation will create a warning log message
[
https://issues.apache.org/jira/browse/CAMEL-10841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-10841:
--
Affects Version/s: 2.17.5
> Move operation will create a warning log message
>
>
> Key: CAMEL-10841
> URL: https://issues.apache.org/jira/browse/CAMEL-10841
> Project: Camel
> Issue Type: Bug
> Components: camel-ftp
>Affects Versions: 2.17.5, 2.18.2
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
>
> I'm using an enpoint like this one :
> -
> sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
>
> With 2.18.2, I have logs like this :
> {noformat}
> 2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
> sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
> Cannot delete file: folder1/folder2/../archive/myfile.txt
> com.jcraft.jsch.SftpException: No such file
> at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
> at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
> at
> org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
> at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
> {noformat}
> the issue was introduced with CAMEL-10712
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CAMEL-10841) Move operation will create a warning log message
Stephan Siano created CAMEL-10841:
-
Summary: Move operation will create a warning log message
Key: CAMEL-10841
URL: https://issues.apache.org/jira/browse/CAMEL-10841
Project: Camel
Issue Type: Bug
Components: camel-ftp
Affects Versions: 2.18.2
Reporter: Stephan Siano
Assignee: Stephan Siano
Priority: Minor
I'm using an enpoint like this one :
-
sftp://myserver/folder1/folder2?idempotent=true=false&...=../archive
With 2.18.2, I have logs like this :
{noformat}
2017-02-15T13:23:47.314 [Camel (camel-1) thread #10 -
sftp://myserver/folder1/folder2] WARN o.a.c.c.file.remote.SftpOperations -
Cannot delete file: folder1/folder2/../archive/myfile.txt
com.jcraft.jsch.SftpException: No such file
at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873)
at com.jcraft.jsch.ChannelSftp.rm(ChannelSftp.java:1985)
at
org.apache.camel.component.file.remote.SftpOperations.deleteFile(SftpOperations.java:435)
at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:100)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CAMEL-10830) Race condition when reading principal for one-way web services
[
https://issues.apache.org/jira/browse/CAMEL-10830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano resolved CAMEL-10830.
---
Resolution: Fixed
Fix Version/s: 2.19.0
> Race condition when reading principal for one-way web services
> --
>
> Key: CAMEL-10830
> URL: https://issues.apache.org/jira/browse/CAMEL-10830
> Project: Camel
> Issue Type: Bug
> Components: camel-cxf
>Affects Versions: 2.16.2
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.19.0
>
>
> This is an issue of the more esoteric kind.
> If camel-cxf is running on Tomcat 7 and the provided web service is a one-way
> webservice and if the robust feature is not set in very rare cases the
> following exception can occur:
> {noformat}
> nowjava.lang.SecurityException: attempting to add an object which is not an
> instance of java.security.Principal to a Subject's Principal Set
> at javax.security.auth.Subject$SecureSet.add(Subject.java:1106)
> at
> java.util.Collections$SynchronizedCollection.add(Collections.java:1636)
> at
> org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfRequest(DefaultCxfBinding.java:275)
> at
> org.apache.camel.component.cxf.CxfConsumer$1.prepareCamelExchange(CxfConsumer.java:187)
> at
> org.apache.camel.component.cxf.CxfConsumer$1.syncInvoke(CxfConsumer.java:132)
> at
> org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:78)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
> at
> org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
> at
> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:137)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at
> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
> at java.lang.Thread.run(Thread.java:807)
> {noformat}
> The reason for that is in the combination of this code
> {code:title=DefaultCxfBinding.java}
> if (securityContext instanceof LoginSecurityContext
> && ((LoginSecurityContext)securityContext).getSubject() != null) {
> camelExchange.getIn().getHeaders().put(Exchange.AUTHENTICATION,
>
> ((LoginSecurityContext)securityContext).getSubject());
> } else if (securityContext != null &&
> securityContext.getUserPrincipal() != null) {
> Subject subject = new Subject();
> subject.getPrincipals().add(securityContext.getUserPrincipal());
> camelExchange.getIn().getHeaders().put(Exchange.AUTHENTICATION,
> subject);
> }
> {code}
> with the implementation of the CXF securtyContext, the way Tomcat implements
> the login context, and the thread context change created by CXF for the
> one-way web services. As a result the behaviour of
> securityContext.getUserPrincipal() may change asynchonously at any time (so
> it may return a principal when the null check happens and may return null on
> the second call). Trying to add null to the principals will create above
> exception.
> The fix for this is to call getUserPrincipal() only once and perform the null
> check and the add() operation with the result.
> Obviously the issue is not testable (because even in the environment where
> this may happen it is very improbable that it can be reproduced).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CAMEL-10830) Race condition when reading principal for one-way web services
Stephan Siano created CAMEL-10830:
-
Summary: Race condition when reading principal for one-way web
services
Key: CAMEL-10830
URL: https://issues.apache.org/jira/browse/CAMEL-10830
Project: Camel
Issue Type: Bug
Components: camel-cxf
Affects Versions: 2.16.2
Reporter: Stephan Siano
Assignee: Stephan Siano
Priority: Minor
This is an issue of the more esoteric kind.
If camel-cxf is running on Tomcat 7 and the provided web service is a one-way
webservice and if the robust feature is not set in very rare cases the
following exception can occur:
{noformat}
nowjava.lang.SecurityException: attempting to add an object which is not an
instance of java.security.Principal to a Subject's Principal Set
at javax.security.auth.Subject$SecureSet.add(Subject.java:1106)
at
java.util.Collections$SynchronizedCollection.add(Collections.java:1636)
at
org.apache.camel.component.cxf.DefaultCxfBinding.populateExchangeFromCxfRequest(DefaultCxfBinding.java:275)
at
org.apache.camel.component.cxf.CxfConsumer$1.prepareCamelExchange(CxfConsumer.java:187)
at
org.apache.camel.component.cxf.CxfConsumer$1.syncInvoke(CxfConsumer.java:132)
at
org.apache.camel.component.cxf.CxfConsumer$1.invoke(CxfConsumer.java:78)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:59)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor$2.run(ServiceInvokerInterceptor.java:126)
at
org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37)
at
org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:131)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:278)
at
org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcessorInterceptor.java:137)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$3.run(AutomaticWorkQueueImpl.java:428)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$AWQThreadFactory$1.run(AutomaticWorkQueueImpl.java:353)
at java.lang.Thread.run(Thread.java:807)
{noformat}
The reason for that is in the combination of this code
{code:title=DefaultCxfBinding.java}
if (securityContext instanceof LoginSecurityContext
&& ((LoginSecurityContext)securityContext).getSubject() != null) {
camelExchange.getIn().getHeaders().put(Exchange.AUTHENTICATION,
((LoginSecurityContext)securityContext).getSubject());
} else if (securityContext != null &&
securityContext.getUserPrincipal() != null) {
Subject subject = new Subject();
subject.getPrincipals().add(securityContext.getUserPrincipal());
camelExchange.getIn().getHeaders().put(Exchange.AUTHENTICATION,
subject);
}
{code}
with the implementation of the CXF securtyContext, the way Tomcat implements
the login context, and the thread context change created by CXF for the one-way
web services. As a result the behaviour of securityContext.getUserPrincipal()
may change asynchonously at any time (so it may return a principal when the
null check happens and may return null on the second call). Trying to add null
to the principals will create above exception.
The fix for this is to call getUserPrincipal() only once and perform the null
check and the add() operation with the result.
Obviously the issue is not testable (because even in the environment where this
may happen it is very improbable that it can be reproduced).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (CAMEL-10712) Camel-SFTP endpoints will silently not delete file on disconnect
[ https://issues.apache.org/jira/browse/CAMEL-10712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-10712. --- Resolution: Fixed Fix Version/s: 2.19.0 2.18.2 2.17.5 > Camel-SFTP endpoints will silently not delete file on disconnect > > > Key: CAMEL-10712 > URL: https://issues.apache.org/jira/browse/CAMEL-10712 > Project: Camel > Issue Type: Bug > Components: camel-ftp >Affects Versions: 2.17.4 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.17.5, 2.18.2, 2.19.0 > > > If an SFTP endpoint is configured to delete files after successful > processing, the processing takes a long time, and the SFTP server closes the > connection while the (successful) processing takes place the file will not be > deleted. There is no log about that (not even on debug level). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10712) Camel-SFTP endpoints will silently not delete file on disconnect
Stephan Siano created CAMEL-10712: - Summary: Camel-SFTP endpoints will silently not delete file on disconnect Key: CAMEL-10712 URL: https://issues.apache.org/jira/browse/CAMEL-10712 Project: Camel Issue Type: Bug Components: camel-ftp Affects Versions: 2.17.4 Reporter: Stephan Siano Priority: Minor If an SFTP endpoint is configured to delete files after successful processing, the processing takes a long time, and the SFTP server closes the connection while the (successful) processing takes place the file will not be deleted. There is no log about that (not even on debug level). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-10712) Camel-SFTP endpoints will silently not delete file on disconnect
[ https://issues.apache.org/jira/browse/CAMEL-10712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-10712: - Assignee: Stephan Siano > Camel-SFTP endpoints will silently not delete file on disconnect > > > Key: CAMEL-10712 > URL: https://issues.apache.org/jira/browse/CAMEL-10712 > Project: Camel > Issue Type: Bug > Components: camel-ftp >Affects Versions: 2.17.4 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > If an SFTP endpoint is configured to delete files after successful > processing, the processing takes a long time, and the SFTP server closes the > connection while the (successful) processing takes place the file will not be > deleted. There is no log about that (not even on debug level). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-10704) XSLT will fail if the XML document contains a default namespace
[
https://issues.apache.org/jira/browse/CAMEL-10704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano resolved CAMEL-10704.
---
Resolution: Fixed
Fix Version/s: 2.19.0
2.18.2
2.17.5
Regression: Regression
> XSLT will fail if the XML document contains a default namespace
> ---
>
> Key: CAMEL-10704
> URL: https://issues.apache.org/jira/browse/CAMEL-10704
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon
>Affects Versions: 2.17.4, 2.18.1
>Reporter: Stephan Siano
>Assignee: Stephan Siano
> Fix For: 2.17.5, 2.18.2, 2.19.0
>
>
> Any XSLT transformation will fail if the XML document that needs to be
> transformed contains a default namespace and camel-saxon is present.
> The same transformation will just work fine without camel-saxon (e.g. if the
> test is executed in camel-core).
> Example: If you try to transform the following XML document with XSLT and
> have camel-saxon in the classpath, an exception will be thrown:
> {code:xml}
>
> http://www.camel.apache.org/envelope;>
> 2.0
>
> {code}
> {noformat}
> org.apache.camel.CamelExecutionException: Exception occurred during execution
> on the exchange: Exchange[ID-WDFN34057358A-51410-1484310448314-0-2]
> at
> org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1710)
> at
> org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:677)
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:515)
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:511)
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:163)
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:168)
> at
> org.apache.camel.component.xslt.PayloadWithDefaultNamespaceTest.test_map_only(PayloadWithDefaultNamespaceTest.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.NullPointerException
> at
> net.sf.saxon.event.ReceivingContentHandler.startPrefixMapping(ReceivingContentHandler.java:269)
> at
> org.apache.camel.converter.jaxp.StAX2SAXSource.parse(StAX2SAXSource.java:140)
> at
>
[jira] [Assigned] (CAMEL-10704) XSLT will fail if the XML document contains a default namespace
[
https://issues.apache.org/jira/browse/CAMEL-10704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano reassigned CAMEL-10704:
-
Assignee: Stephan Siano
> XSLT will fail if the XML document contains a default namespace
> ---
>
> Key: CAMEL-10704
> URL: https://issues.apache.org/jira/browse/CAMEL-10704
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon
>Affects Versions: 2.17.4, 2.18.1
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>
> Any XSLT transformation will fail if the XML document that needs to be
> transformed contains a default namespace and camel-saxon is present.
> The same transformation will just work fine without camel-saxon (e.g. if the
> test is executed in camel-core).
> Example: If you try to transform the following XML document with XSLT and
> have camel-saxon in the classpath, an exception will be thrown:
> {code:xml}
>
> http://www.camel.apache.org/envelope;>
> 2.0
>
> {code}
> {noformat}
> org.apache.camel.CamelExecutionException: Exception occurred during execution
> on the exchange: Exchange[ID-WDFN34057358A-51410-1484310448314-0-2]
> at
> org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1710)
> at
> org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:677)
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:515)
> at
> org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:511)
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:163)
> at
> org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:168)
> at
> org.apache.camel.component.xslt.PayloadWithDefaultNamespaceTest.test_map_only(PayloadWithDefaultNamespaceTest.java:38)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: java.lang.NullPointerException
> at
> net.sf.saxon.event.ReceivingContentHandler.startPrefixMapping(ReceivingContentHandler.java:269)
> at
> org.apache.camel.converter.jaxp.StAX2SAXSource.parse(StAX2SAXSource.java:140)
> at
> org.apache.camel.converter.jaxp.StAX2SAXSource.parse(StAX2SAXSource.java:343)
> at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:451)
> at
[jira] [Created] (CAMEL-10704) XSLT will fail if the XML document contains a default namespace
Stephan Siano created CAMEL-10704:
-
Summary: XSLT will fail if the XML document contains a default
namespace
Key: CAMEL-10704
URL: https://issues.apache.org/jira/browse/CAMEL-10704
Project: Camel
Issue Type: Bug
Components: camel-saxon
Affects Versions: 2.18.1, 2.17.4
Reporter: Stephan Siano
Any XSLT transformation will fail if the XML document that needs to be
transformed contains a default namespace and camel-saxon is present.
The same transformation will just work fine without camel-saxon (e.g. if the
test is executed in camel-core).
Example: If you try to transform the following XML document with XSLT and have
camel-saxon in the classpath, an exception will be thrown:
{code:xml}
http://www.camel.apache.org/envelope;>
2.0
{code}
{noformat}
org.apache.camel.CamelExecutionException: Exception occurred during execution
on the exchange: Exchange[ID-WDFN34057358A-51410-1484310448314-0-2]
at
org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1710)
at
org.apache.camel.util.ExchangeHelper.extractResultBody(ExchangeHelper.java:677)
at
org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:515)
at
org.apache.camel.impl.DefaultProducerTemplate.extractResultBody(DefaultProducerTemplate.java:511)
at
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:163)
at
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:168)
at
org.apache.camel.component.xslt.PayloadWithDefaultNamespaceTest.test_map_only(PayloadWithDefaultNamespaceTest.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: java.lang.NullPointerException
at
net.sf.saxon.event.ReceivingContentHandler.startPrefixMapping(ReceivingContentHandler.java:269)
at
org.apache.camel.converter.jaxp.StAX2SAXSource.parse(StAX2SAXSource.java:140)
at
org.apache.camel.converter.jaxp.StAX2SAXSource.parse(StAX2SAXSource.java:343)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:451)
at net.sf.saxon.event.Sender.send(Sender.java:153)
at net.sf.saxon.Controller.makeSourceTree(Controller.java:1927)
at
net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:573)
at net.sf.saxon.jaxp.TransformerImpl.transform(TransformerImpl.java:185)
at
[jira] [Resolved] (CAMEL-10392) HTTP session handling in Camel routes
[ https://issues.apache.org/jira/browse/CAMEL-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-10392. --- Resolution: Fixed > HTTP session handling in Camel routes > - > > Key: CAMEL-10392 > URL: https://issues.apache.org/jira/browse/CAMEL-10392 > Project: Camel > Issue Type: Improvement > Components: camel-ahc, camel-cxf, camel-http, camel-http-common, > camel-http4, camel-jetty, camel-netty4-http, camel-restlet, camel-undertow >Affects Versions: 2.18.0 >Reporter: Stephan Siano >Assignee: Stephan Siano > Fix For: 2.19.0 > > > Provide support for client side HTTP session handling for different HTTP > based consumer endpoints. > An interface (CookieHandler) and two implementations ExchangeCookieHandler > and InstanceCookieHandler will be provided in camel-http-common. > The endpoints in the mentioned HTTP based components are extended by a > cookieHandler parameter. > If no CookieHandler is defined on the endpoint it will continue working as it > did before (without any session support). > An ExchangeCookieHandler will maintain session cookies on exchange basis. If > the same URI is called multiple times from the same exchange state will be > maintained, different exchanges do not share state. This can be used for > stateful services. > An InstanceCookieHandler will maintain session information within it's > instance. This means that state will be shared across exchanges. This > behaviour is similar to the existing cookieStore parameter for the > camel-http4 component (but available for all mentioned components, not only > camel-http4) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-10392) HTTP session handling in Camel routes
[ https://issues.apache.org/jira/browse/CAMEL-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-10392: -- Fix Version/s: 2.19.0 > HTTP session handling in Camel routes > - > > Key: CAMEL-10392 > URL: https://issues.apache.org/jira/browse/CAMEL-10392 > Project: Camel > Issue Type: Improvement > Components: camel-ahc, camel-cxf, camel-http, camel-http-common, > camel-http4, camel-jetty, camel-netty4-http, camel-restlet, camel-undertow >Affects Versions: 2.18.0 >Reporter: Stephan Siano >Assignee: Stephan Siano > Fix For: 2.19.0 > > > Provide support for client side HTTP session handling for different HTTP > based consumer endpoints. > An interface (CookieHandler) and two implementations ExchangeCookieHandler > and InstanceCookieHandler will be provided in camel-http-common. > The endpoints in the mentioned HTTP based components are extended by a > cookieHandler parameter. > If no CookieHandler is defined on the endpoint it will continue working as it > did before (without any session support). > An ExchangeCookieHandler will maintain session cookies on exchange basis. If > the same URI is called multiple times from the same exchange state will be > maintained, different exchanges do not share state. This can be used for > stateful services. > An InstanceCookieHandler will maintain session information within it's > instance. This means that state will be shared across exchanges. This > behaviour is similar to the existing cookieStore parameter for the > camel-http4 component (but available for all mentioned components, not only > camel-http4) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CAMEL-10392) HTTP session handling in Camel routes
[ https://issues.apache.org/jira/browse/CAMEL-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-10392 started by Stephan Siano. - > HTTP session handling in Camel routes > - > > Key: CAMEL-10392 > URL: https://issues.apache.org/jira/browse/CAMEL-10392 > Project: Camel > Issue Type: Improvement > Components: camel-ahc, camel-cxf, camel-http, camel-http-common, > camel-http4, camel-jetty, camel-netty4-http, camel-restlet, camel-undertow >Affects Versions: 2.18.0 >Reporter: Stephan Siano >Assignee: Stephan Siano > > Provide support for client side HTTP session handling for different HTTP > based consumer endpoints. > An interface (CookieHandler) and two implementations ExchangeCookieHandler > and InstanceCookieHandler will be provided in camel-http-common. > The endpoints in the mentioned HTTP based components are extended by a > cookieHandler parameter. > If no CookieHandler is defined on the endpoint it will continue working as it > did before (without any session support). > An ExchangeCookieHandler will maintain session cookies on exchange basis. If > the same URI is called multiple times from the same exchange state will be > maintained, different exchanges do not share state. This can be used for > stateful services. > An InstanceCookieHandler will maintain session information within it's > instance. This means that state will be shared across exchanges. This > behaviour is similar to the existing cookieStore parameter for the > camel-http4 component (but available for all mentioned components, not only > camel-http4) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-10392) HTTP session handling in Camel routes
[ https://issues.apache.org/jira/browse/CAMEL-10392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-10392: -- Component/s: camel-http > HTTP session handling in Camel routes > - > > Key: CAMEL-10392 > URL: https://issues.apache.org/jira/browse/CAMEL-10392 > Project: Camel > Issue Type: Improvement > Components: camel-ahc, camel-cxf, camel-http, camel-http-common, > camel-http4, camel-jetty, camel-netty4-http, camel-restlet, camel-undertow >Affects Versions: 2.18.0 >Reporter: Stephan Siano >Assignee: Stephan Siano > > Provide support for client side HTTP session handling for different HTTP > based consumer endpoints. > An interface (CookieHandler) and two implementations ExchangeCookieHandler > and InstanceCookieHandler will be provided in camel-http-common. > The endpoints in the mentioned HTTP based components are extended by a > cookieHandler parameter. > If no CookieHandler is defined on the endpoint it will continue working as it > did before (without any session support). > An ExchangeCookieHandler will maintain session cookies on exchange basis. If > the same URI is called multiple times from the same exchange state will be > maintained, different exchanges do not share state. This can be used for > stateful services. > An InstanceCookieHandler will maintain session information within it's > instance. This means that state will be shared across exchanges. This > behaviour is similar to the existing cookieStore parameter for the > camel-http4 component (but available for all mentioned components, not only > camel-http4) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10392) HTTP session handling in Camel routes
Stephan Siano created CAMEL-10392: - Summary: HTTP session handling in Camel routes Key: CAMEL-10392 URL: https://issues.apache.org/jira/browse/CAMEL-10392 Project: Camel Issue Type: Improvement Components: camel-ahc, camel-cxf, camel-http-common, camel-http4, camel-jetty, camel-netty4-http, camel-restlet, camel-undertow Affects Versions: 2.18.0 Reporter: Stephan Siano Assignee: Stephan Siano Provide support for client side HTTP session handling for different HTTP based consumer endpoints. An interface (CookieHandler) and two implementations ExchangeCookieHandler and InstanceCookieHandler will be provided in camel-http-common. The endpoints in the mentioned HTTP based components are extended by a cookieHandler parameter. If no CookieHandler is defined on the endpoint it will continue working as it did before (without any session support). An ExchangeCookieHandler will maintain session cookies on exchange basis. If the same URI is called multiple times from the same exchange state will be maintained, different exchanges do not share state. This can be used for stateful services. An InstanceCookieHandler will maintain session information within it's instance. This means that state will be shared across exchanges. This behaviour is similar to the existing cookieStore parameter for the camel-http4 component (but available for all mentioned components, not only camel-http4) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-10370) Conversion to CxfPayload throws Exception for Non-XML payload
[ https://issues.apache.org/jira/browse/CAMEL-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano resolved CAMEL-10370. --- Resolution: Fixed Fix Version/s: 2.18.1 > Conversion to CxfPayload throws Exception for Non-XML payload > - > > Key: CAMEL-10370 > URL: https://issues.apache.org/jira/browse/CAMEL-10370 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.17.3 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.19.0, 2.17.4, 2.18.1 > > > The CxfPayloadConverter throws a runtime Exception for (optional) conversion > from byte[] to CxfPayload instead of returning null when the body is not > valid XML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CAMEL-10370) Conversion to CxfPayload throws Exception for Non-XML payload
[ https://issues.apache.org/jira/browse/CAMEL-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-10370 started by Stephan Siano. - > Conversion to CxfPayload throws Exception for Non-XML payload > - > > Key: CAMEL-10370 > URL: https://issues.apache.org/jira/browse/CAMEL-10370 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.17.3 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.19.0, 2.17.4 > > > The CxfPayloadConverter throws a runtime Exception for (optional) conversion > from byte[] to CxfPayload instead of returning null when the body is not > valid XML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-10370) Conversion to CxfPayload throws Exception for Non-XML payload
[ https://issues.apache.org/jira/browse/CAMEL-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-10370: -- Fix Version/s: 2.17.4 2.19.0 > Conversion to CxfPayload throws Exception for Non-XML payload > - > > Key: CAMEL-10370 > URL: https://issues.apache.org/jira/browse/CAMEL-10370 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.17.3 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > Fix For: 2.19.0, 2.17.4 > > > The CxfPayloadConverter throws a runtime Exception for (optional) conversion > from byte[] to CxfPayload instead of returning null when the body is not > valid XML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-10370) Conversion to CxfPayload throws Exception for Non-XML payload
[ https://issues.apache.org/jira/browse/CAMEL-10370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano reassigned CAMEL-10370: - Assignee: Stephan Siano > Conversion to CxfPayload throws Exception for Non-XML payload > - > > Key: CAMEL-10370 > URL: https://issues.apache.org/jira/browse/CAMEL-10370 > Project: Camel > Issue Type: Bug > Components: camel-cxf >Affects Versions: 2.17.3 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > The CxfPayloadConverter throws a runtime Exception for (optional) conversion > from byte[] to CxfPayload instead of returning null when the body is not > valid XML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10370) Conversion to CxfPayload throws Exception for Non-XML payload
Stephan Siano created CAMEL-10370: - Summary: Conversion to CxfPayload throws Exception for Non-XML payload Key: CAMEL-10370 URL: https://issues.apache.org/jira/browse/CAMEL-10370 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.17.3 Reporter: Stephan Siano Priority: Minor The CxfPayloadConverter throws a runtime Exception for (optional) conversion from byte[] to CxfPayload instead of returning null when the body is not valid XML. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-10302) Extract body from nested multiparts
[
https://issues.apache.org/jira/browse/CAMEL-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano resolved CAMEL-10302.
---
Resolution: Fixed
Fix Version/s: 2.18.0
> Extract body from nested multiparts
> ---
>
> Key: CAMEL-10302
> URL: https://issues.apache.org/jira/browse/CAMEL-10302
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.17.3
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
> Fix For: 2.18.0
>
>
> The camel-mail component currently handle mails with attachments where the
> mail body is a plain text message. In this case the MIME-Structure looks as
> follows:
> {noformat}
> mulipart/mixed
> |- text/plain -> body
> |- image/png-> attachment[0]
> |- text/plain -> attachment[1]
> {noformat}
> However if the mail is e.g. sent by Outlook and the mail body contains
> formating and a picture, the resulting multipart structure might look like
> this
> {noformat}
> multipart/mixed
> |- multipart/related
> | |- multipart/alternative
> | | |- text/plain -> body
> | | |- text/html
> | |- image/png -> attachment[0]
> |- text/plain-> attachment[1]
> {noformat}
> Without the patch, the attachments will be as expected, but the body will be
> the same as attachment\[1\] (or some bogus string if the mail does not
> contain a text attachment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10302) Extract body from nested multiparts
[
https://issues.apache.org/jira/browse/CAMEL-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-10302:
--
Description:
The camel-mail component currently handle mails with attachments where the mail
body is a plain text message. In this case the MIME-Structure looks as follows:
{noformat}
mulipart/mixed
|- text/plain -> body
|- image/png-> attachment[0]
|- text/plain -> attachment[1]
{noformat}
However if the mail is e.g. sent by Outlook and the mail body contains
formating and a picture, the resulting multipart structure might look like this
{noformat}
multipart/mixed
|- multipart/related
| |- multipart/alternative
| | |- text/plain -> body
| | |- text/html
| |- image/png -> attachment[0]
|- text/plain-> attachment[1]
{noformat}
Without the patch, the attachments will be as expected, but the body will be
the same as attachment\[1\] (or some bogus string if the mail does not contain
a text attachment).
was:
The camel-mail component currently handle mails with attachments where the mail
body is a plain text message. In this case the MIME-Structure looks as follows:
{noformat}
mulipart/mixed
|- text/plain -> body
|- image/png -> attachment[0]
|- text/plain -> attachment[1]
{noformat}
However if the mail is e.g. sent by Outlook and the mail body contains
formating and a picture, the resulting multipart structure might look like this
{noformat}
multipart/mixed
|- multipart/related
| |- multipart/alternative
| | |- text/plain -> body
| | |- text/html
| |- image/png -> attachment[0]
|- text/plain -> attachment[1]
{noformat}
Without the patch, the attachments will be as expected, but the body will be
the same as attachment[1] (or some bogus string if the mail does not contain a
text attachment).
> Extract body from nested multiparts
> ---
>
> Key: CAMEL-10302
> URL: https://issues.apache.org/jira/browse/CAMEL-10302
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.17.3
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
>
> The camel-mail component currently handle mails with attachments where the
> mail body is a plain text message. In this case the MIME-Structure looks as
> follows:
> {noformat}
> mulipart/mixed
> |- text/plain -> body
> |- image/png-> attachment[0]
> |- text/plain -> attachment[1]
> {noformat}
> However if the mail is e.g. sent by Outlook and the mail body contains
> formating and a picture, the resulting multipart structure might look like
> this
> {noformat}
> multipart/mixed
> |- multipart/related
> | |- multipart/alternative
> | | |- text/plain -> body
> | | |- text/html
> | |- image/png -> attachment[0]
> |- text/plain-> attachment[1]
> {noformat}
> Without the patch, the attachments will be as expected, but the body will be
> the same as attachment\[1\] (or some bogus string if the mail does not
> contain a text attachment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10302) Extract body from nested multiparts
[
https://issues.apache.org/jira/browse/CAMEL-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephan Siano updated CAMEL-10302:
--
Description:
The camel-mail component currently handle mails with attachments where the mail
body is a plain text message. In this case the MIME-Structure looks as follows:
{noformat}
mulipart/mixed
|- text/plain -> body
|- image/png -> attachment[0]
|- text/plain -> attachment[1]
{noformat}
However if the mail is e.g. sent by Outlook and the mail body contains
formating and a picture, the resulting multipart structure might look like this
{noformat}
multipart/mixed
|- multipart/related
| |- multipart/alternative
| | |- text/plain -> body
| | |- text/html
| |- image/png -> attachment[0]
|- text/plain -> attachment[1]
{noformat}
Without the patch, the attachments will be as expected, but the body will be
the same as attachment[1] (or some bogus string if the mail does not contain a
text attachment).
was:
The camel-mail component currently handle mails with attachments where the mail
body is a plain text message. In this case the MIME-Structure looks as follows:
[noformat]
mulipart/mixed
|- text/plain -> body
|- image/png -> attachment[0]
|- text/plain -> attachment[1]
[noformat]
However if the mail is e.g. sent by Outlook and the mail body contains
formating and a picture, the resulting multipart structure might look like this
[noformat]
multipart/mixed
|- multipart/related
| |- multipart/alternative
| | |- text/plain -> body
| | |- text/html
| |- image/png -> attachment[0]
|- text/plain -> attachment[1]
[noformat]
Without the patch, the attachments will be as expected, but the body will be
the same as attachment[1] (or some bogus string if the mail does not contain a
text attachment).
> Extract body from nested multiparts
> ---
>
> Key: CAMEL-10302
> URL: https://issues.apache.org/jira/browse/CAMEL-10302
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.17.3
>Reporter: Stephan Siano
>Assignee: Stephan Siano
>Priority: Minor
>
> The camel-mail component currently handle mails with attachments where the
> mail body is a plain text message. In this case the MIME-Structure looks as
> follows:
> {noformat}
> mulipart/mixed
> |- text/plain -> body
> |- image/png -> attachment[0]
> |- text/plain -> attachment[1]
> {noformat}
> However if the mail is e.g. sent by Outlook and the mail body contains
> formating and a picture, the resulting multipart structure might look like
> this
> {noformat}
> multipart/mixed
> |- multipart/related
> | |- multipart/alternative
> | | |- text/plain -> body
> | | |- text/html
> | |- image/png -> attachment[0]
> |- text/plain -> attachment[1]
> {noformat}
> Without the patch, the attachments will be as expected, but the body will be
> the same as attachment[1] (or some bogus string if the mail does not contain
> a text attachment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-10302) Extract body from nested multiparts
[ https://issues.apache.org/jira/browse/CAMEL-10302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephan Siano updated CAMEL-10302: -- Assignee: Stephan Siano Patch Info: Patch Available Component/s: camel-mail > Extract body from nested multiparts > --- > > Key: CAMEL-10302 > URL: https://issues.apache.org/jira/browse/CAMEL-10302 > Project: Camel > Issue Type: Improvement > Components: camel-mail >Affects Versions: 2.17.3 >Reporter: Stephan Siano >Assignee: Stephan Siano >Priority: Minor > > The camel-mail component currently handle mails with attachments where the > mail body is a plain text message. In this case the MIME-Structure looks as > follows: > [noformat] > mulipart/mixed > |- text/plain -> body > |- image/png -> attachment[0] > |- text/plain -> attachment[1] > [noformat] > However if the mail is e.g. sent by Outlook and the mail body contains > formating and a picture, the resulting multipart structure might look like > this > [noformat] > multipart/mixed > |- multipart/related > | |- multipart/alternative > | | |- text/plain -> body > | | |- text/html > | |- image/png -> attachment[0] > |- text/plain -> attachment[1] > [noformat] > Without the patch, the attachments will be as expected, but the body will be > the same as attachment[1] (or some bogus string if the mail does not contain > a text attachment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-10302) Extract body from nested multiparts
Stephan Siano created CAMEL-10302: - Summary: Extract body from nested multiparts Key: CAMEL-10302 URL: https://issues.apache.org/jira/browse/CAMEL-10302 Project: Camel Issue Type: Improvement Affects Versions: 2.17.3 Reporter: Stephan Siano Priority: Minor The camel-mail component currently handle mails with attachments where the mail body is a plain text message. In this case the MIME-Structure looks as follows: [noformat] mulipart/mixed |- text/plain -> body |- image/png -> attachment[0] |- text/plain -> attachment[1] [noformat] However if the mail is e.g. sent by Outlook and the mail body contains formating and a picture, the resulting multipart structure might look like this [noformat] multipart/mixed |- multipart/related | |- multipart/alternative | | |- text/plain -> body | | |- text/html | |- image/png -> attachment[0] |- text/plain -> attachment[1] [noformat] Without the patch, the attachments will be as expected, but the body will be the same as attachment[1] (or some bogus string if the mail does not contain a text attachment). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
