[jira] [Commented] (CAMEL-16938) StackOverflowError in RedeliveryErrorHandler when using transacted
[ https://issues.apache.org/jira/browse/CAMEL-16938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564993#comment-17564993 ] Christoph Giera commented on CAMEL-16938: - Can we have a downgrade to 3.11? We also have this problem and we can't upgrade now. > StackOverflowError in RedeliveryErrorHandler when using transacted > -- > > Key: CAMEL-16938 > URL: https://issues.apache.org/jira/browse/CAMEL-16938 > Project: Camel > Issue Type: Bug > Components: came-core >Affects Versions: 3.11.0 >Reporter: Wojciech Strzałka >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.13.0 > > Attachments: StackOverflowTest.java > > > After migration from Camel 2.25.x to 3.11.0 there is issue with redelivery > logic causing stack trace overflow eventually. > See the stack trace: > Caused by: java.lang.StackOverflowError > at > com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:769) > at > com.google.common.util.concurrent.SettableFuture.setException(SettableFuture.java:53) > at > com.google.common.cache.LocalCache$LoadingValueReference.setException(LocalCache.java:3503) > at > com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3549) > at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2278) > at > com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2155) > at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2045) > at com.google.common.cache.LocalCache.get(LocalCache.java:3951) > at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3974) > at > com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4935) > at > com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4941) > at com.foo.bar.AtomicCache.get(AtomicCache.java:34) > at > com.foo.bar.CachingZoneServiceRegistry.findWithZoneId(CachingZoneServiceRegistry.java:55) > at > com.foo.bar.PersistenceBasedRoutingsLoader.lambda$getDestinationFunction$1(PersistenceBasedRoutingsLoader.java:34) > at > com.foo.bar.RoutingDestination.getTargetDestinationsFor(RoutingDestination.java:66) > at > com.foo.bar.RoutingDestination.getClientCamelUris(RoutingDestination.java:59) > at sun.reflect.GeneratedMethodAccessor461.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.camel.support.ObjectHelper.invokeMethodSafe(ObjectHelper.java:380) > at org.apache.camel.component.bean.MethodInfo.invoke(MethodInfo.java:494) > at org.apache.camel.component.bean.MethodInfo$1.doProceed(MethodInfo.java:316) > at org.apache.camel.component.bean.MethodInfo$1.proceed(MethodInfo.java:286) > at > org.apache.camel.component.bean.AbstractBeanProcessor.process(AbstractBeanProcessor.java:146) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83) > at > org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41) > at > org.apache.camel.language.bean.BeanExpression.invokeBean(BeanExpression.java:347) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:202) > at > org.apache.camel.language.bean.BeanExpression.evaluate(BeanExpression.java:214) > at > org.apache.camel.processor.SetPropertyProcessor.process(SetPropertyProcessor.java:47) > at > org.apache.camel.impl.engine.DefaultAsyncProcessorAwaitManager.process(DefaultAsyncProcessorAwaitManager.java:83) > at > org.apache.camel.support.AsyncProcessorSupport.process(AsyncProcessorSupport.java:41) > at > org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:369) > at org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:109) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:179) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:59) > at > org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:274) > at > org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:377) > at org.apache.camel.processor.Pipeline$PipelineTask.run(Pipeline.java:109) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:179) > at > org.apache.camel.impl.engine.DefaultReactiveExecutor.schedule(DefaultReactiveExecutor.java:59) > at > org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:274) > at > org.apache.camel.impl.engine.CamelInternalProcessor.
[jira] [Commented] (CAMEL-12724) Simple SFTP-to-File integration with charset options fails
[
https://issues.apache.org/jira/browse/CAMEL-12724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404343#comment-17404343
]
Christoph Giera commented on CAMEL-12724:
-
:(
> Simple SFTP-to-File integration with charset options fails
> --
>
> Key: CAMEL-12724
> URL: https://issues.apache.org/jira/browse/CAMEL-12724
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-ftp
>Affects Versions: 2.22.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.21.3, 2.22.1, 2.23.0
>
> Attachments: SftpToFileTest.zip
>
>
> Simple SFTP-to-File integrations with {{charset}} conversion like:
> {code:java}
> from("sftp://sample@localhost:/in?password=password&delete=true&charset=ISO-8859-1";)
> .to("file:/tmp/samples-camel/SftpToFileTest/out?charset=UTF-8");
> {code}
> fails to output a file in {{/tmp/samples-camel/SftpToFileTest/out/}}
> correctly. Depending on the combinations, it sometimes converts the charset
> wrongly and sometimes it simply doesn't output a file to the target dir.
> The root cause is that {{SftpOperations}} puts {{ByteArrayOutputStream}}
> instead of {{byte[]}} or {{InputStream}} to the exchange file body when
> retrieving a file:
> https://github.com/apache/camel/blob/camel-2.22.0/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java#L718-L720
> which then results in no converter from {{OutputStream}} to
> {{java.io.Reader}} being found in {{GenericFileConverter}} downstream, and
> thus the File producer handles a {{RemoteFile}} awkwardly when outputting a
> file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-12724) Simple SFTP-to-File integration with charset options fails
[
https://issues.apache.org/jira/browse/CAMEL-12724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404321#comment-17404321
]
Christoph Giera commented on CAMEL-12724:
-
Is it possible to downgrade it to 2.20.x too?
> Simple SFTP-to-File integration with charset options fails
> --
>
> Key: CAMEL-12724
> URL: https://issues.apache.org/jira/browse/CAMEL-12724
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-ftp
>Affects Versions: 2.22.0
>Reporter: Tadayoshi Sato
>Assignee: Tadayoshi Sato
>Priority: Major
> Fix For: 2.21.3, 2.22.1, 2.23.0
>
> Attachments: SftpToFileTest.zip
>
>
> Simple SFTP-to-File integrations with {{charset}} conversion like:
> {code:java}
> from("sftp://sample@localhost:/in?password=password&delete=true&charset=ISO-8859-1";)
> .to("file:/tmp/samples-camel/SftpToFileTest/out?charset=UTF-8");
> {code}
> fails to output a file in {{/tmp/samples-camel/SftpToFileTest/out/}}
> correctly. Depending on the combinations, it sometimes converts the charset
> wrongly and sometimes it simply doesn't output a file to the target dir.
> The root cause is that {{SftpOperations}} puts {{ByteArrayOutputStream}}
> instead of {{byte[]}} or {{InputStream}} to the exchange file body when
> retrieving a file:
> https://github.com/apache/camel/blob/camel-2.22.0/components/camel-ftp/src/main/java/org/apache/camel/component/file/remote/SftpOperations.java#L718-L720
> which then results in no converter from {{OutputStream}} to
> {{java.io.Reader}} being found in {{GenericFileConverter}} downstream, and
> thus the File producer handles a {{RemoteFile}} awkwardly when outputting a
> file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CAMEL-15274) camel-spring-boot - Add back http endpoint for route information
[ https://issues.apache.org/jira/browse/CAMEL-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320093#comment-17320093 ] Christoph Giera commented on CAMEL-15274: - OK that's fine :) , did i misread that camel 3.4 is the last version with java 8 support or was this changed some time ago? > camel-spring-boot - Add back http endpoint for route information > > > Key: CAMEL-15274 > URL: https://issues.apache.org/jira/browse/CAMEL-15274 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot >Reporter: Claus Ibsen >Assignee: Ramu >Priority: Major > Fix For: 3.5.0 > > > In Camel 2.x we had spring boot actuator that could output route details, eg > a list of the routes and their state, and some metrics. > It was also possible to stop/start routes etc. > However the latter was a concern for security. > But having a basic http endpoint service to dump route details would be good. > It should be disabled by default and only be a read-only service if enabled. > The old code in 2.x can be of inspiration. > And the old code is not compatible with newer spring boot so it needs to be > migrated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-15274) camel-spring-boot - Add back http endpoint for route information
[ https://issues.apache.org/jira/browse/CAMEL-15274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320071#comment-17320071 ] Christoph Giera commented on CAMEL-15274: - I think this is needed in the 3.4 version(LTS) too. 3.4 is the last version with java 8 support. So 3.5 forces all to use java 11(which is not possible for all) and going back to 3.3 means that you don't use a LTS version. > camel-spring-boot - Add back http endpoint for route information > > > Key: CAMEL-15274 > URL: https://issues.apache.org/jira/browse/CAMEL-15274 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot >Reporter: Claus Ibsen >Assignee: Ramu >Priority: Major > Fix For: 3.5.0 > > > In Camel 2.x we had spring boot actuator that could output route details, eg > a list of the routes and their state, and some metrics. > It was also possible to stop/start routes etc. > However the latter was a concern for security. > But having a basic http endpoint service to dump route details would be good. > It should be disabled by default and only be a read-only service if enabled. > The old code in 2.x can be of inspiration. > And the old code is not compatible with newer spring boot so it needs to be > migrated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CAMEL-16356) custom LdapEndpoint: inconsistent type for pageSize leads to NPE
[
https://issues.apache.org/jira/browse/CAMEL-16356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17301783#comment-17301783
]
Christoph Giera commented on CAMEL-16356:
-
https://github.com/apache/camel/pull/5215
> custom LdapEndpoint: inconsistent type for pageSize leads to NPE
> -
>
> Key: CAMEL-16356
> URL: https://issues.apache.org/jira/browse/CAMEL-16356
> Project: Camel
> Issue Type: Bug
> Components: camel-ldap
>Affects Versions: 2.20.2, 3.8.0
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.9.0
>
>
> The getter/setter for pageSize have inconsistent/incorrect types:
> {code:java}
> public void setPageSize(Integer pageSize) {
> this.pageSize = pageSize;
> }
> public int getPageSize() {
> return pageSize;
> } {code}
> If you want to create a custom ldap component and you subclass the endpoint
> you have to use the getter which leads to an nullpointer exception:
> {code:java}
> public Producer createProducer() throws Exception {
> return new MyLdapProducer(this, remainingLdap, getBase(),
> toSearchControlScope(getScope()), ->getPageSize()<-, getReturnedAttributes());
> } {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-16356) custom LdapEndpoint: inconsistent type for pageSize leads to NPE
Christoph Giera created CAMEL-16356:
---
Summary: custom LdapEndpoint: inconsistent type for pageSize leads
to NPE
Key: CAMEL-16356
URL: https://issues.apache.org/jira/browse/CAMEL-16356
Project: Camel
Issue Type: Bug
Components: camel-ldap
Affects Versions: 3.8.0, 2.20.2
Reporter: Christoph Giera
The getter/setter for pageSize have inconsistent/incorrect types:
{code:java}
public void setPageSize(Integer pageSize) {
this.pageSize = pageSize;
}
public int getPageSize() {
return pageSize;
} {code}
If you want to create a custom ldap component and you subclass the endpoint you
have to use the getter which leads to an nullpointer exception:
{code:java}
public Producer createProducer() throws Exception {
return new MyLdapProducer(this, remainingLdap, getBase(),
toSearchControlScope(getScope()), ->getPageSize()<-, getReturnedAttributes());
} {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14548) resilience4j doesn't catch configuration from spring boot
[
https://issues.apache.org/jira/browse/CAMEL-14548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-14548:
Description:
Configuring the resilience4j component with spring boot like in the example
[https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
doesn't work correctly.
{code:java}
.circuitBreaker()
// see application.properties how resilience is configured
.to("http://localhost:9090/service1";)
{code}
The configuration in application.properties is not taken into account.
was:
Configuring the resilience4j component with spring boot like in the example
[https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
doesn't work correctly.
{code:java}
//
.circuitBreaker()
// see application.properties how resilience is configured
.to("http://localhost:9090/service1";)
{code}
The configuration in application.properties is not taken into account.
> resilience4j doesn't catch configuration from spring boot
> -
>
> Key: CAMEL-14548
> URL: https://issues.apache.org/jira/browse/CAMEL-14548
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Christoph Giera
>Priority: Major
>
> Configuring the resilience4j component with spring boot like in the example
> [https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
> doesn't work correctly.
> {code:java}
> .circuitBreaker()
> // see application.properties how resilience is configured
> .to("http://localhost:9090/service1";)
> {code}
>
> The configuration in application.properties is not taken into account.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CAMEL-14548) resilience4j doesn't catch configuration from spring boot
[
https://issues.apache.org/jira/browse/CAMEL-14548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-14548:
Description:
Configuring the resilience4j component with spring boot like in the example
[https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
doesn't work correctly.
{code:java}
//
.circuitBreaker()
// see application.properties how resilience is configured
.to("http://localhost:9090/service1";)
{code}
The configuration in application.properties is not taken into account.
was:
Configuring the resilience4j component with spring boot like in the example
[https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
doesn't work correctly.
{code:java}
//
.circuitBreaker()
// see application.properties how resilience is configured
.to("http://localhost:9090/service1";)
{code}
The configuration in application.properties is not taken into account.
> resilience4j doesn't catch configuration from spring boot
> -
>
> Key: CAMEL-14548
> URL: https://issues.apache.org/jira/browse/CAMEL-14548
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Christoph Giera
>Priority: Major
>
> Configuring the resilience4j component with spring boot like in the example
> [https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
> doesn't work correctly.
> {code:java}
> //
> .circuitBreaker()
> // see application.properties how resilience is configured
> .to("http://localhost:9090/service1";)
> {code}
>
> The configuration in application.properties is not taken into account.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-14548) resilience4j doesn't catch configuration from spring boot
Christoph Giera created CAMEL-14548:
---
Summary: resilience4j doesn't catch configuration from spring boot
Key: CAMEL-14548
URL: https://issues.apache.org/jira/browse/CAMEL-14548
Project: Camel
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Christoph Giera
Configuring the resilience4j component with spring boot like in the example
[https://github.com/apache/camel-spring-boot/blob/master/examples/camel-example-spring-boot-resilience4j/client/src/main/java/sample/camel/ClientRoute.java]
doesn't work correctly.
{code:java}
//
.circuitBreaker()
// see application.properties how resilience is configured
.to("http://localhost:9090/service1";)
{code}
The configuration in application.properties is not taken into account.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CAMEL-13691) Add resilience4j circuit breaker
Christoph Giera created CAMEL-13691:
---
Summary: Add resilience4j circuit breaker
Key: CAMEL-13691
URL: https://issues.apache.org/jira/browse/CAMEL-13691
Project: Camel
Issue Type: New Feature
Reporter: Christoph Giera
Hystrix is no longer in active development, netflix uses resilience4j for new
internal projects, see [https://github.com/Netflix/Hystrix#Hystrix%20Status]
Camel should also add a resilience4j component/java dsl.
Idea for java dsl: instead of adding resilience4j on the same level like
hystrix add an additional level "circuitBreaker" with the childs hystrix,
resilience4j...
{noformat}
from(endpoint)
.circuitBreaker()
.useHystrix()
.to(endpoint)
.endCircuitBreaker();{noformat}
{noformat}
from(endpoint)
.circuitBreaker()
.useResilience4j()
.to(endpoint)
.endCircuitBreaker();{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861976#comment-16861976
]
Christoph Giera commented on CAMEL-13621:
-
You mean using the underlying URISupport.sanitizeUri? We will loose masking for
xml and json values.
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121/OpenJDK 11.0.3
>
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861917#comment-16861917
]
Christoph Giera commented on CAMEL-13621:
-
The use-case is pretty simple:
We trace our route executions in a DB table. E.g. if an error occured we store
it in a DB field . It's possible that this information contains sensitive
data(like password in a camel uri). I knew that there exists a solution for
masking in the camel framework because the log component has a masking option
and there I found the DefaultMaskingFormatter. I thought "when the log
component uses this I can also use it :) "
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121/OpenJDK 11.0.3
>
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-13621:
Environment:
Camel 2.20.2
Oracle JDK 8u121/OpenJDK 11.0.3
was:
Camel 2.20.2
Oracle JDK 8u121
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121/OpenJDK 11.0.3
>
>Reporter: Christoph Giera
>Priority: Minor
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860799#comment-16860799
]
Christoph Giera commented on CAMEL-13621:
-
It's not so easy to show or explain the StackOverflowError, I've attached 2
screenshots which are the results of the same test(FormatTest.java). Executing
this test results in ~50% errors(see ExecuteTest_2.PNG) and ~50% success(see
ExecuteTest_1.PNG). This is really weird because it's the same test. Maybe it
has something to do with [https://bugs.openjdk.java.net/browse/JDK-6328855] but
I'm not sure.
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121
>Reporter: Christoph Giera
>Priority: Minor
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-13621:
Attachment: ExecuteTest_1.PNG
ExecuteTest_2.PNG
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121
>Reporter: Christoph Giera
>Priority: Minor
> Attachments: ExecuteTest_1.PNG, ExecuteTest_2.PNG, FormatTest.java,
> FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860619#comment-16860619
]
Christoph Giera commented on CAMEL-13621:
-
Added FormatUriTest.java. The DefaultMaskingFormatter is used in the log
component and also provides options for json and xml formatting. So I assumed
that multiline strings should not be a problem at all. E.g. a pretty printed
xml contains line breaks.
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121
>Reporter: Christoph Giera
>Priority: Minor
> Attachments: FormatTest.java, FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
[
https://issues.apache.org/jira/browse/CAMEL-13621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-13621:
Attachment: FormatUriTest.java
> DefaultMaskingFormatter: & is ignored as ending character
> -
>
> Key: CAMEL-13621
> URL: https://issues.apache.org/jira/browse/CAMEL-13621
> Project: Camel
> Issue Type: Bug
>Affects Versions: 2.20.2
> Environment: Camel 2.20.2
> Oracle JDK 8u121
>Reporter: Christoph Giera
>Priority: Minor
> Attachments: FormatTest.java, FormatUriTest.java
>
>
> Using the DefaultMaskingFormatter and formatting a string that contains for
> example
> {noformat}
> password=mypass&nextParameter=nextvalue{noformat}
> should be masked to
> {noformat}
> password="x"&nextParameter=nextvalue{noformat}
> Instead of this the & is ignored(the next parameter will swallowed up) and
> the output looks like the following
> {noformat}
> password="x"{noformat}
>
> Additionaly StackoverflowErrors occur when formatting/masking bigger strings
> with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13621) DefaultMaskingFormatter: & is ignored as ending character
Christoph Giera created CAMEL-13621:
---
Summary: DefaultMaskingFormatter: & is ignored as ending character
Key: CAMEL-13621
URL: https://issues.apache.org/jira/browse/CAMEL-13621
Project: Camel
Issue Type: Bug
Affects Versions: 2.20.2
Environment: Camel 2.20.2
Oracle JDK 8u121
Reporter: Christoph Giera
Attachments: FormatTest.java
Using the DefaultMaskingFormatter and formatting a string that contains for
example
{noformat}
password=mypass&nextParameter=nextvalue{noformat}
should be masked to
{noformat}
password="x"&nextParameter=nextvalue{noformat}
Instead of this the & is ignored(the next parameter will swallowed up) and the
output looks like the following
{noformat}
password="x"{noformat}
Additionaly StackoverflowErrors occur when formatting/masking bigger strings
with line breaks, see example attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13214) camel-mail: Add headerFilterStrategy option to component level
[
https://issues.apache.org/jira/browse/CAMEL-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785629#comment-16785629
]
Christoph Giera commented on CAMEL-13214:
-
Pull request created.
> camel-mail: Add headerFilterStrategy option to component level
> --
>
> Key: CAMEL-13214
> URL: https://issues.apache.org/jira/browse/CAMEL-13214
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.20.2
>Reporter: Christoph Giera
>Priority: Minor
> Fix For: 3.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently it's not possible to change/customize the headerFilterStrategy for
> all camel-mail endpoints because it has to be configured on endpoint level.
> In the cxf component it's possible to configure it on component level too, so
> it's possible to provide a global headerFilterStrategy:
> Example:
> {noformat}
> CxfComponent comp = camelContext.getComponent("cxf",
> CxfComponent.class);
> CxfHeaderFilterStrategy strategy = new
> CxfHeaderFilterStrategy();
> strategy.setOutFilterPattern(
> "");
> comp.setHeaderFilterStrategy(strategy);{noformat}
> It would be an improvement to add the headerFilterStrategy option also to
> component level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13214) camel-mail: Add headerFilterStrategy option to component level
[
https://issues.apache.org/jira/browse/CAMEL-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-13214:
Description:
Currently it's not possible to change/customize the headerFilterStrategy for
all camel-mail endpoints because it has to be configured on endpoint level.
In the cxf component it's possible to configure it on component level too, so
it's possible to provide a global headerFilterStrategy:
Example:
{noformat}
CxfComponent comp = camelContext.getComponent("cxf",
CxfComponent.class);
CxfHeaderFilterStrategy strategy = new
CxfHeaderFilterStrategy();
strategy.setOutFilterPattern(
"");
comp.setHeaderFilterStrategy(strategy);{noformat}
It would be an improvement to add the headerFilterStrategy option also to
component level.
was:
Currently it's not possible to change/customize the headerFilterStrategy for
all camel-mail endpoints because it has to be configured on endpoint level.
In the cxf component it's possible to configure it on component level, so it's
possible to provide a global headerFilterStrategy:
Example:
{noformat}
CxfComponent comp = camelContext.getComponent("cxf",
CxfComponent.class);
CxfHeaderFilterStrategy strategy = new
CxfHeaderFilterStrategy();
strategy.setOutFilterPattern(
"");
comp.setHeaderFilterStrategy(strategy);{noformat}
It would be an improvement to move the headerFilterStrategy from endpoint to
component level.
> camel-mail: Add headerFilterStrategy option to component level
> --
>
> Key: CAMEL-13214
> URL: https://issues.apache.org/jira/browse/CAMEL-13214
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.20.2
>Reporter: Christoph Giera
>Priority: Minor
>
> Currently it's not possible to change/customize the headerFilterStrategy for
> all camel-mail endpoints because it has to be configured on endpoint level.
> In the cxf component it's possible to configure it on component level too, so
> it's possible to provide a global headerFilterStrategy:
> Example:
> {noformat}
> CxfComponent comp = camelContext.getComponent("cxf",
> CxfComponent.class);
> CxfHeaderFilterStrategy strategy = new
> CxfHeaderFilterStrategy();
> strategy.setOutFilterPattern(
> "");
> comp.setHeaderFilterStrategy(strategy);{noformat}
> It would be an improvement to add the headerFilterStrategy option also to
> component level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-13214) camel-mail: Add headerFilterStrategy option to component level
[
https://issues.apache.org/jira/browse/CAMEL-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1677#comment-1677
]
Christoph Giera commented on CAMEL-13214:
-
I've edited the issue.
> camel-mail: Add headerFilterStrategy option to component level
> --
>
> Key: CAMEL-13214
> URL: https://issues.apache.org/jira/browse/CAMEL-13214
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.20.2
>Reporter: Christoph Giera
>Priority: Minor
>
> Currently it's not possible to change/customize the headerFilterStrategy for
> all camel-mail endpoints because it has to be configured on endpoint level.
> In the cxf component it's possible to configure it on component level too, so
> it's possible to provide a global headerFilterStrategy:
> Example:
> {noformat}
> CxfComponent comp = camelContext.getComponent("cxf",
> CxfComponent.class);
> CxfHeaderFilterStrategy strategy = new
> CxfHeaderFilterStrategy();
> strategy.setOutFilterPattern(
> "");
> comp.setHeaderFilterStrategy(strategy);{noformat}
> It would be an improvement to add the headerFilterStrategy option also to
> component level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-13214) camel-mail: Add headerFilterStrategy option to component level
[
https://issues.apache.org/jira/browse/CAMEL-13214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-13214:
Summary: camel-mail: Add headerFilterStrategy option to component level
(was: camel-mail: Move headerFilterStrategy from endpoint to component level)
> camel-mail: Add headerFilterStrategy option to component level
> --
>
> Key: CAMEL-13214
> URL: https://issues.apache.org/jira/browse/CAMEL-13214
> Project: Camel
> Issue Type: Improvement
> Components: camel-mail
>Affects Versions: 2.20.2
>Reporter: Christoph Giera
>Priority: Minor
>
> Currently it's not possible to change/customize the headerFilterStrategy for
> all camel-mail endpoints because it has to be configured on endpoint level.
> In the cxf component it's possible to configure it on component level, so
> it's possible to provide a global headerFilterStrategy:
> Example:
> {noformat}
> CxfComponent comp = camelContext.getComponent("cxf",
> CxfComponent.class);
> CxfHeaderFilterStrategy strategy = new
> CxfHeaderFilterStrategy();
> strategy.setOutFilterPattern(
> "");
> comp.setHeaderFilterStrategy(strategy);{noformat}
> It would be an improvement to move the headerFilterStrategy from endpoint to
> component level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-13214) camel-mail: Move headerFilterStrategy from endpoint to component level
Christoph Giera created CAMEL-13214:
---
Summary: camel-mail: Move headerFilterStrategy from endpoint to
component level
Key: CAMEL-13214
URL: https://issues.apache.org/jira/browse/CAMEL-13214
Project: Camel
Issue Type: Improvement
Components: camel-mail
Affects Versions: 2.20.2
Reporter: Christoph Giera
Currently it's not possible to change/customize the headerFilterStrategy for
all camel-mail endpoints because it has to be configured on endpoint level.
In the cxf component it's possible to configure it on component level, so it's
possible to provide a global headerFilterStrategy:
Example:
{noformat}
CxfComponent comp = camelContext.getComponent("cxf",
CxfComponent.class);
CxfHeaderFilterStrategy strategy = new
CxfHeaderFilterStrategy();
strategy.setOutFilterPattern(
"");
comp.setHeaderFilterStrategy(strategy);{noformat}
It would be an improvement to move the headerFilterStrategy from endpoint to
component level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-7536) camel mail: content-transfer-encoding configurable
[ https://issues.apache.org/jira/browse/CAMEL-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14049860#comment-14049860 ] Christoph Giera commented on CAMEL-7536: Personally I don't like the idea of a global resolver in this case. In my opinion camel and/or smtp does a good job when it is autodetecting the content-transfer-encoding. We have a lot of mailing routes, but only one needs this "override" of the content-transfer-encoding, so I think it's more viable to use an uri parameter. We also try to don't update our camel-context.xml file as it has too much impact on all our processes, so configuration as uri parameter is much more confortable as configuration on the component it self. But if you say it has to be that way, I will do it. I just wanted to give an input or rather have implemented this the way I think it is most usefull :). > camel mail: content-transfer-encoding configurable > -- > > Key: CAMEL-7536 > URL: https://issues.apache.org/jira/browse/CAMEL-7536 > Project: Camel > Issue Type: New Feature > Components: camel-mail >Reporter: Christoph Giera > Fix For: 2.14.0 > > Attachments: camel-mail.patch > > > It should be possible to set the content-transfer-encoding for attachments, > normally it will be automatically determined based on the content of the > attachment. > see > http://camel.465427.n5.nabble.com/camel-mail-content-transfer-encoding-configurable-td5752504.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7536) camel mail: content-transfer-encoding configurable
[ https://issues.apache.org/jira/browse/CAMEL-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Giera updated CAMEL-7536: --- Attachment: camel-mail.patch Here is the patch for my solution: I've added a contentTransferEncodingResolver parameter that can be added to the uri, for example: smtp://host?to=1...@123.com&contentTransferEncodingResolver=. It's a bit different to the contentType resolver, but I think it's much easier to configure it via uri parameter. > camel mail: content-transfer-encoding configurable > -- > > Key: CAMEL-7536 > URL: https://issues.apache.org/jira/browse/CAMEL-7536 > Project: Camel > Issue Type: New Feature > Components: camel-mail >Reporter: Christoph Giera > Fix For: 2.14.0 > > Attachments: camel-mail.patch > > > It should be possible to set the content-transfer-encoding for attachments, > normally it will be automatically determined based on the content of the > attachment. > see > http://camel.465427.n5.nabble.com/camel-mail-content-transfer-encoding-configurable-td5752504.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-7536) camel mail: content-transfer-encoding configurable
[ https://issues.apache.org/jira/browse/CAMEL-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Giera updated CAMEL-7536: --- Patch Info: Patch Available > camel mail: content-transfer-encoding configurable > -- > > Key: CAMEL-7536 > URL: https://issues.apache.org/jira/browse/CAMEL-7536 > Project: Camel > Issue Type: New Feature > Components: camel-mail >Reporter: Christoph Giera > Fix For: 2.14.0 > > > It should be possible to set the content-transfer-encoding for attachments, > normally it will be automatically determined based on the content of the > attachment. > see > http://camel.465427.n5.nabble.com/camel-mail-content-transfer-encoding-configurable-td5752504.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7536) camel mail: content-transfer-encoding configurable
Christoph Giera created CAMEL-7536: -- Summary: camel mail: content-transfer-encoding configurable Key: CAMEL-7536 URL: https://issues.apache.org/jira/browse/CAMEL-7536 Project: Camel Issue Type: New Feature Components: camel-mail Reporter: Christoph Giera Fix For: 2.14.0 It should be possible to set the content-transfer-encoding for attachments, normally it will be automatically determined based on the content of the attachment. see http://camel.465427.n5.nabble.com/camel-mail-content-transfer-encoding-configurable-td5752504.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CAMEL-7452) beanRef is caching instances - unwanted behavior
Christoph Giera created CAMEL-7452: -- Summary: beanRef is caching instances - unwanted behavior Key: CAMEL-7452 URL: https://issues.apache.org/jira/browse/CAMEL-7452 Project: Camel Issue Type: Bug Affects Versions: 2.13.0 Reporter: Christoph Giera After upgrading from 2.11.0 to 2.13.0 the behavior of beanRef has changed(unwanted behavior). Beans only get instanted once, even if the cache option is explicitly set to "false". see http://camel.465427.n5.nabble.com/beanRef-is-caching-instances-in-camel-2-13-0-unwanted-behavior-td5751335.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CAMEL-6964) Camel FileComponent: Done file will not be removed if moveFailed option is configured and an error occurs
[ https://issues.apache.org/jira/browse/CAMEL-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Giera updated CAMEL-6964: --- Attachment: camel.patch First time git, hopefully correct. Patch is for "master" version > Camel FileComponent: Done file will not be removed if moveFailed option is > configured and an error occurs > - > > Key: CAMEL-6964 > URL: https://issues.apache.org/jira/browse/CAMEL-6964 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.11.0 >Reporter: Christoph Giera > Attachments: camel.patch > > > Only the "real" file is moved to the directory specified with the > moveFailed-option. The done file still exists in the source folder and will > not be deleted. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6964) Camel FileComponent: Done file will not be removed if moveFailed option is configured and an error occurs
[ https://issues.apache.org/jira/browse/CAMEL-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Giera updated CAMEL-6964: --- Patch Info: Patch Available > Camel FileComponent: Done file will not be removed if moveFailed option is > configured and an error occurs > - > > Key: CAMEL-6964 > URL: https://issues.apache.org/jira/browse/CAMEL-6964 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.11.0 >Reporter: Christoph Giera > > Only the "real" file is moved to the directory specified with the > moveFailed-option. The done file still exists in the source folder and will > not be deleted. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CAMEL-6964) Camel FileComponent: Done file will not be removed if moveFailed option is configured and an error occurs
Christoph Giera created CAMEL-6964: -- Summary: Camel FileComponent: Done file will not be removed if moveFailed option is configured and an error occurs Key: CAMEL-6964 URL: https://issues.apache.org/jira/browse/CAMEL-6964 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.11.0 Reporter: Christoph Giera Only the "real" file is moved to the directory specified with the moveFailed-option. The done file still exists in the source folder and will not be deleted. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CAMEL-6045) Camel Email Component Missing Attachments
[
https://issues.apache.org/jira/browse/CAMEL-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-6045:
---
Attachment: MailBinding.java.patch
> Camel Email Component Missing Attachments
> --
>
> Key: CAMEL-6045
> URL: https://issues.apache.org/jira/browse/CAMEL-6045
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.6.0
>Reporter: Christoph Giera
> Attachments: MailBinding.java.patch
>
>
> see
> http://camel.465427.n5.nabble.com/Camel-Email-Component-Missing-Attachments-td3386382.html#a5727102
> The disposition field is optional(see RFC 2183), so it is possible that camel
> misses attachments.
> {noformat}
> if (disposition != null &&
> (disposition.equalsIgnoreCase(Part.ATTACHMENT) ||
> disposition.equalsIgnoreCase(Part.INLINE))) {
> // only add named attachments
> String fileName = part.getFileName();
> if (fileName != null) {
> LOG.debug("Mail contains file attachment: " +
> fileName);
> // Parts marked with a disposition of Part.ATTACHMENT
> are clearly attachments
> CollectionHelper.appendValue(map, fileName,
> part.getDataHandler());
> }
> }
> {noformat}
> Adding the fileName check to the if should resolve the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-6045) Camel Email Component Missing Attachments
[
https://issues.apache.org/jira/browse/CAMEL-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Giera updated CAMEL-6045:
---
Patch Info: Patch Available
patch added
> Camel Email Component Missing Attachments
> --
>
> Key: CAMEL-6045
> URL: https://issues.apache.org/jira/browse/CAMEL-6045
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.6.0
>Reporter: Christoph Giera
> Attachments: MailBinding.java.patch
>
>
> see
> http://camel.465427.n5.nabble.com/Camel-Email-Component-Missing-Attachments-td3386382.html#a5727102
> The disposition field is optional(see RFC 2183), so it is possible that camel
> misses attachments.
> {noformat}
> if (disposition != null &&
> (disposition.equalsIgnoreCase(Part.ATTACHMENT) ||
> disposition.equalsIgnoreCase(Part.INLINE))) {
> // only add named attachments
> String fileName = part.getFileName();
> if (fileName != null) {
> LOG.debug("Mail contains file attachment: " +
> fileName);
> // Parts marked with a disposition of Part.ATTACHMENT
> are clearly attachments
> CollectionHelper.appendValue(map, fileName,
> part.getDataHandler());
> }
> }
> {noformat}
> Adding the fileName check to the if should resolve the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6045) Camel Email Component Missing Attachments
[
https://issues.apache.org/jira/browse/CAMEL-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573535#comment-13573535
]
Christoph Giera commented on CAMEL-6045:
I still use camel 2.6 due to some customer restrictions(java 5), but I couldn't
find a branch for 2.6 to provide a patch for this version. So i will add a
patch for the trunk version.
> Camel Email Component Missing Attachments
> --
>
> Key: CAMEL-6045
> URL: https://issues.apache.org/jira/browse/CAMEL-6045
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.6.0
>Reporter: Christoph Giera
>
> see
> http://camel.465427.n5.nabble.com/Camel-Email-Component-Missing-Attachments-td3386382.html#a5727102
> The disposition field is optional(see RFC 2183), so it is possible that camel
> misses attachments.
> {noformat}
> if (disposition != null &&
> (disposition.equalsIgnoreCase(Part.ATTACHMENT) ||
> disposition.equalsIgnoreCase(Part.INLINE))) {
> // only add named attachments
> String fileName = part.getFileName();
> if (fileName != null) {
> LOG.debug("Mail contains file attachment: " +
> fileName);
> // Parts marked with a disposition of Part.ATTACHMENT
> are clearly attachments
> CollectionHelper.appendValue(map, fileName,
> part.getDataHandler());
> }
> }
> {noformat}
> Adding the fileName check to the if should resolve the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-6045) Camel Email Component Missing Attachments
[
https://issues.apache.org/jira/browse/CAMEL-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13573532#comment-13573532
]
Christoph Giera commented on CAMEL-6045:
Test with changed if worked on my side. I've just added the fileName check to
the if:
{noformat}
if ((disposition != null && (disposition
.equalsIgnoreCase(Part.ATTACHMENT) || disposition
.equalsIgnoreCase(Part.INLINE)))
|| fileName != null) {
LOG.debug("Mail contains file
attachment: " + fileName);
// Parts marked with a disposition of
Part.ATTACHMENT
// are clearly attachments
CollectionHelper.appendValue(map,
fileName,
part.getDataHandler());
}
{noformat}
> Camel Email Component Missing Attachments
> --
>
> Key: CAMEL-6045
> URL: https://issues.apache.org/jira/browse/CAMEL-6045
> Project: Camel
> Issue Type: Bug
> Components: camel-mail
>Affects Versions: 2.6.0
>Reporter: Christoph Giera
>
> see
> http://camel.465427.n5.nabble.com/Camel-Email-Component-Missing-Attachments-td3386382.html#a5727102
> The disposition field is optional(see RFC 2183), so it is possible that camel
> misses attachments.
> {noformat}
> if (disposition != null &&
> (disposition.equalsIgnoreCase(Part.ATTACHMENT) ||
> disposition.equalsIgnoreCase(Part.INLINE))) {
> // only add named attachments
> String fileName = part.getFileName();
> if (fileName != null) {
> LOG.debug("Mail contains file attachment: " +
> fileName);
> // Parts marked with a disposition of Part.ATTACHMENT
> are clearly attachments
> CollectionHelper.appendValue(map, fileName,
> part.getDataHandler());
> }
> }
> {noformat}
> Adding the fileName check to the if should resolve the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CAMEL-6045) Camel Email Component Missing Attachments
Christoph Giera created CAMEL-6045:
--
Summary: Camel Email Component Missing Attachments
Key: CAMEL-6045
URL: https://issues.apache.org/jira/browse/CAMEL-6045
Project: Camel
Issue Type: Bug
Components: camel-mail
Affects Versions: 2.6.0
Reporter: Christoph Giera
see
http://camel.465427.n5.nabble.com/Camel-Email-Component-Missing-Attachments-td3386382.html#a5727102
The disposition field is optional(see RFC 2183), so it is possible that camel
misses attachments.
{noformat}
if (disposition != null &&
(disposition.equalsIgnoreCase(Part.ATTACHMENT) ||
disposition.equalsIgnoreCase(Part.INLINE))) {
// only add named attachments
String fileName = part.getFileName();
if (fileName != null) {
LOG.debug("Mail contains file attachment: " + fileName);
// Parts marked with a disposition of Part.ATTACHMENT
are clearly attachments
CollectionHelper.appendValue(map, fileName,
part.getDataHandler());
}
}
{noformat}
Adding the fileName check to the if should resolve the issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
