[jira] [Updated] (CAMEL-18494) camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer
[ https://issues.apache.org/jira/browse/CAMEL-18494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18494: Fix Version/s: 3.x > camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer > -- > > Key: CAMEL-18494 > URL: https://issues.apache.org/jira/browse/CAMEL-18494 > Project: Camel > Issue Type: New Feature > Components: camel-mllp >Affects Versions: 3.18.2 > Environment: Test environment: current environment is Camel / Quarkus >Reporter: Joseph >Priority: Minor > Fix For: 3.x > > > When payloads are known to be always larger that the hardcoded > MIN_BUFFER_SIZE of 2048, this results in the resizing of the buffer. > [https://github.com/apache/camel/blob/c4b5791237bbf27af7b54bbd0d14b7c6944dff1f/components/camel-mllp/src/main/java/org/apache/camel/component/mllp/internal/MllpSocketBuffer.java#L39] > There is also the belief that when a gc event occurs, the buffer then returns > to the default size of MIN_BUFFER_SIZE, which again results in another > resizing of the buffer when larger than MIN_BUFFER_SIZE payloads arrive. > It is the hope that allowing for a customized MIN_BUFFER_SIZE would result in > an overall faster sustained throughput when the payload size is known to be > larger than MIN_BUFFER_SIZE (2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18494) camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer
[ https://issues.apache.org/jira/browse/CAMEL-18494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602494#comment-17602494 ] Claus Ibsen commented on CAMEL-18494: - You are welcome to work on a PR that allows to configure this buffer size > camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer > -- > > Key: CAMEL-18494 > URL: https://issues.apache.org/jira/browse/CAMEL-18494 > Project: Camel > Issue Type: New Feature > Components: camel-mllp >Affects Versions: 3.18.2 > Environment: Test environment: current environment is Camel / Quarkus >Reporter: Joseph >Priority: Minor > > When payloads are known to be always larger that the hardcoded > MIN_BUFFER_SIZE of 2048, this results in the resizing of the buffer. > [https://github.com/apache/camel/blob/c4b5791237bbf27af7b54bbd0d14b7c6944dff1f/components/camel-mllp/src/main/java/org/apache/camel/component/mllp/internal/MllpSocketBuffer.java#L39] > There is also the belief that when a gc event occurs, the buffer then returns > to the default size of MIN_BUFFER_SIZE, which again results in another > resizing of the buffer when larger than MIN_BUFFER_SIZE payloads arrive. > It is the hope that allowing for a customized MIN_BUFFER_SIZE would result in > an overall faster sustained throughput when the payload size is known to be > larger than MIN_BUFFER_SIZE (2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18495) Apache Chemistry is deprecated
[ https://issues.apache.org/jira/browse/CAMEL-18495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18495. - Resolution: Fixed > Apache Chemistry is deprecated > -- > > Key: CAMEL-18495 > URL: https://issues.apache.org/jira/browse/CAMEL-18495 > Project: Camel > Issue Type: Task > Components: camel-cmis >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 3.19.0 > > > The project is retired and likely unmaintained: > https://chemistry.apache.org/java/opencmis.html. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18451) camel-azure-eventhubs: Add support for Azure-AD authentication
[ https://issues.apache.org/jira/browse/CAMEL-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602493#comment-17602493 ] Claus Ibsen commented on CAMEL-18451: - camel-karaf is OK Babak I think its okay to backport if this PR does not change default behaviour, eg users today will not be affected. > camel-azure-eventhubs: Add support for Azure-AD authentication > -- > > Key: CAMEL-18451 > URL: https://issues.apache.org/jira/browse/CAMEL-18451 > Project: Camel > Issue Type: New Feature > Components: camel-azure-eventhubs >Affects Versions: 3.18.1 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18493) camel-netty-http: Add maxInitialLineLength, maxChunkSize configuration parameters
[
https://issues.apache.org/jira/browse/CAMEL-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602491#comment-17602491
]
Michael Frankfurter commented on CAMEL-18493:
-
Thanks for accepting. Can't wait for 3.19 then ;)
> camel-netty-http: Add maxInitialLineLength, maxChunkSize configuration
> parameters
> -
>
> Key: CAMEL-18493
> URL: https://issues.apache.org/jira/browse/CAMEL-18493
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty-http
>Affects Versions: 3.x
>Reporter: Michael Frankfurter
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 3.19.0
>
>
> Camel Netty HTTP has the option {{maxHeaderSize}} which goes down into
> {{HttpServerInitializerFactory}} and is used at constructor
> {{HttpRequestDecoder}}.
> The other two options {{maxInitialLineLength}} and {{maxChunkSize}} which
> might be necessary to be configured here are not exposed but would be good if
> so.
> Patch is already available:
> https://github.com/micfra/camel/tree/camel-netty-http-ext-configuration -
> Pull request follows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18492:
Issue Type: Improvement (was: Bug)
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Improvement
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Major
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18494) camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer
[ https://issues.apache.org/jira/browse/CAMEL-18494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18494: Summary: camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer (was: Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer) > camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer > -- > > Key: CAMEL-18494 > URL: https://issues.apache.org/jira/browse/CAMEL-18494 > Project: Camel > Issue Type: New Feature > Components: camel-mllp >Affects Versions: 3.18.2 > Environment: Test environment: current environment is Camel / Quarkus >Reporter: Joseph >Priority: Major > > When payloads are known to be always larger that the hardcoded > MIN_BUFFER_SIZE of 2048, this results in the resizing of the buffer. > [https://github.com/apache/camel/blob/c4b5791237bbf27af7b54bbd0d14b7c6944dff1f/components/camel-mllp/src/main/java/org/apache/camel/component/mllp/internal/MllpSocketBuffer.java#L39] > There is also the belief that when a gc event occurs, the buffer then returns > to the default size of MIN_BUFFER_SIZE, which again results in another > resizing of the buffer when larger than MIN_BUFFER_SIZE payloads arrive. > It is the hope that allowing for a customized MIN_BUFFER_SIZE would result in > an overall faster sustained throughput when the payload size is known to be > larger than MIN_BUFFER_SIZE (2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18493) camel-netty-http: Add maxInitialLineLength, maxChunkSize configuration parameters
[
https://issues.apache.org/jira/browse/CAMEL-18493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18493.
-
Assignee: Claus Ibsen
Resolution: Fixed
Thanks for reporting and the PR
> camel-netty-http: Add maxInitialLineLength, maxChunkSize configuration
> parameters
> -
>
> Key: CAMEL-18493
> URL: https://issues.apache.org/jira/browse/CAMEL-18493
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty-http
>Affects Versions: 3.x
>Reporter: Michael Frankfurter
>Assignee: Claus Ibsen
>Priority: Trivial
> Fix For: 3.19.0
>
>
> Camel Netty HTTP has the option {{maxHeaderSize}} which goes down into
> {{HttpServerInitializerFactory}} and is used at constructor
> {{HttpRequestDecoder}}.
> The other two options {{maxInitialLineLength}} and {{maxChunkSize}} which
> might be necessary to be configured here are not exposed but would be good if
> so.
> Patch is already available:
> https://github.com/micfra/camel/tree/camel-netty-http-ext-configuration -
> Pull request follows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18494) camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer
[ https://issues.apache.org/jira/browse/CAMEL-18494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18494: Priority: Minor (was: Major) > camel-mllp - Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer > -- > > Key: CAMEL-18494 > URL: https://issues.apache.org/jira/browse/CAMEL-18494 > Project: Camel > Issue Type: New Feature > Components: camel-mllp >Affects Versions: 3.18.2 > Environment: Test environment: current environment is Camel / Quarkus >Reporter: Joseph >Priority: Minor > > When payloads are known to be always larger that the hardcoded > MIN_BUFFER_SIZE of 2048, this results in the resizing of the buffer. > [https://github.com/apache/camel/blob/c4b5791237bbf27af7b54bbd0d14b7c6944dff1f/components/camel-mllp/src/main/java/org/apache/camel/component/mllp/internal/MllpSocketBuffer.java#L39] > There is also the belief that when a gc event occurs, the buffer then returns > to the default size of MIN_BUFFER_SIZE, which again results in another > resizing of the buffer when larger than MIN_BUFFER_SIZE payloads arrive. > It is the hope that allowing for a customized MIN_BUFFER_SIZE would result in > an overall faster sustained throughput when the payload size is known to be > larger than MIN_BUFFER_SIZE (2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18492:
Priority: Minor (was: Major)
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Improvement
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Minor
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18496) Remove deprecated components
[ https://issues.apache.org/jira/browse/CAMEL-18496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18496: Fix Version/s: 3.x > Remove deprecated components > > > Key: CAMEL-18496 > URL: https://issues.apache.org/jira/browse/CAMEL-18496 > Project: Camel > Issue Type: Task >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 3.x > > > * camel-ahc: CAMEL-17667 > * camel-ahc-ws: CAMEL-17667 > * camel-dozer: CAMEL-18455 > * camel-cmis: https://issues.apache.org/jira/browse/CAMEL-18495 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18496) Remove deprecated components
[ https://issues.apache.org/jira/browse/CAMEL-18496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602472#comment-17602472 ] Claus Ibsen commented on CAMEL-18496: - And we should look for more components to deprecate > Remove deprecated components > > > Key: CAMEL-18496 > URL: https://issues.apache.org/jira/browse/CAMEL-18496 > Project: Camel > Issue Type: Task >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > * camel-ahc: CAMEL-17667 > * camel-ahc-ws: CAMEL-17667 > * camel-dozer: CAMEL-18455 > * camel-cmis: https://issues.apache.org/jira/browse/CAMEL-18495 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18496) Remove deprecated components
[ https://issues.apache.org/jira/browse/CAMEL-18496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602470#comment-17602470 ] Claus Ibsen commented on CAMEL-18496: - Yeah lets removed them after next LTS > Remove deprecated components > > > Key: CAMEL-18496 > URL: https://issues.apache.org/jira/browse/CAMEL-18496 > Project: Camel > Issue Type: Task >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > * camel-ahc: CAMEL-17667 > * camel-ahc-ws: CAMEL-17667 > * camel-dozer: CAMEL-18455 > * camel-cmis: https://issues.apache.org/jira/browse/CAMEL-18495 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18496) Remove deprecated components
[ https://issues.apache.org/jira/browse/CAMEL-18496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602470#comment-17602470 ] Claus Ibsen edited comment on CAMEL-18496 at 9/9/22 4:57 PM: - Yeah lets removed them after next LTS The ahc could technically be removed sooner as they were deprecated before 3.18 LTS was (Author: davsclaus): Yeah lets removed them after next LTS > Remove deprecated components > > > Key: CAMEL-18496 > URL: https://issues.apache.org/jira/browse/CAMEL-18496 > Project: Camel > Issue Type: Task >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > * camel-ahc: CAMEL-17667 > * camel-ahc-ws: CAMEL-17667 > * camel-dozer: CAMEL-18455 > * camel-cmis: https://issues.apache.org/jira/browse/CAMEL-18495 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18495) Apache Chemistry is deprecated
[ https://issues.apache.org/jira/browse/CAMEL-18495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18495: Fix Version/s: 3.19.0 > Apache Chemistry is deprecated > -- > > Key: CAMEL-18495 > URL: https://issues.apache.org/jira/browse/CAMEL-18495 > Project: Camel > Issue Type: Task > Components: camel-cmis >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 3.19.0 > > > The project is retired and likely unmaintained: > https://chemistry.apache.org/java/opencmis.html. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18496) Remove deprecated components
[ https://issues.apache.org/jira/browse/CAMEL-18496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602437#comment-17602437 ] Otavio Rodolfo Piske commented on CAMEL-18496: -- [~acosentino] [~davsclaus]: FYI ... for when we decide to remove these deprecated components. > Remove deprecated components > > > Key: CAMEL-18496 > URL: https://issues.apache.org/jira/browse/CAMEL-18496 > Project: Camel > Issue Type: Task >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > * camel-ahc: CAMEL-17667 > * camel-ahc-ws: CAMEL-17667 > * camel-dozer: CAMEL-18455 > * camel-cmis: https://issues.apache.org/jira/browse/CAMEL-18495 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18496) Remove deprecated components
Otavio Rodolfo Piske created CAMEL-18496: Summary: Remove deprecated components Key: CAMEL-18496 URL: https://issues.apache.org/jira/browse/CAMEL-18496 Project: Camel Issue Type: Task Reporter: Otavio Rodolfo Piske Assignee: Otavio Rodolfo Piske * camel-ahc: CAMEL-17667 * camel-ahc-ws: CAMEL-17667 * camel-dozer: CAMEL-18455 * camel-cmis: https://issues.apache.org/jira/browse/CAMEL-18495 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18495) Apache Chemistry is deprecated
[ https://issues.apache.org/jira/browse/CAMEL-18495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18495: - Component/s: camel-cmis > Apache Chemistry is deprecated > -- > > Key: CAMEL-18495 > URL: https://issues.apache.org/jira/browse/CAMEL-18495 > Project: Camel > Issue Type: Task > Components: camel-cmis >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > The project is retired and likely unmaintained: > https://chemistry.apache.org/java/opencmis.html. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18495) Apache Chemistry is deprecated
Otavio Rodolfo Piske created CAMEL-18495: Summary: Apache Chemistry is deprecated Key: CAMEL-18495 URL: https://issues.apache.org/jira/browse/CAMEL-18495 Project: Camel Issue Type: Task Reporter: Otavio Rodolfo Piske Assignee: Otavio Rodolfo Piske The project is retired and likely unmaintained: https://chemistry.apache.org/java/opencmis.html. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18455) Dozer project is not active anymore
[ https://issues.apache.org/jira/browse/CAMEL-18455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18455: - Component/s: camel-dozer > Dozer project is not active anymore > --- > > Key: CAMEL-18455 > URL: https://issues.apache.org/jira/browse/CAMEL-18455 > Project: Camel > Issue Type: Task > Components: camel-dozer >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 3.19.0 > > > As noted in the project webpage, it is not being maintained anymore and > should not be considered for future projects. We need to mark it as > deprecated and remove it. > > Page: https://github.com/DozerMapper/dozer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18494) Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer
Joseph created CAMEL-18494: -- Summary: Allow the ability to set MIN_BUFFER_SIZE for SocketBuffer Key: CAMEL-18494 URL: https://issues.apache.org/jira/browse/CAMEL-18494 Project: Camel Issue Type: New Feature Components: camel-mllp Affects Versions: 3.18.2 Environment: Test environment: current environment is Camel / Quarkus Reporter: Joseph When payloads are known to be always larger that the hardcoded MIN_BUFFER_SIZE of 2048, this results in the resizing of the buffer. [https://github.com/apache/camel/blob/c4b5791237bbf27af7b54bbd0d14b7c6944dff1f/components/camel-mllp/src/main/java/org/apache/camel/component/mllp/internal/MllpSocketBuffer.java#L39] There is also the belief that when a gc event occurs, the buffer then returns to the default size of MIN_BUFFER_SIZE, which again results in another resizing of the buffer when larger than MIN_BUFFER_SIZE payloads arrive. It is the hope that allowing for a customized MIN_BUFFER_SIZE would result in an overall faster sustained throughput when the payload size is known to be larger than MIN_BUFFER_SIZE (2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18493) camel-netty-http: Add maxInitialLineLength, maxChunkSize configuration parameters
Michael Frankfurter created CAMEL-18493:
---
Summary: camel-netty-http: Add maxInitialLineLength, maxChunkSize
configuration parameters
Key: CAMEL-18493
URL: https://issues.apache.org/jira/browse/CAMEL-18493
Project: Camel
Issue Type: Improvement
Components: camel-netty-http
Affects Versions: 3.x
Reporter: Michael Frankfurter
Fix For: 3.19.0
Camel Netty HTTP has the option {{maxHeaderSize}} which goes down into
{{HttpServerInitializerFactory}} and is used at constructor
{{HttpRequestDecoder}}.
The other two options {{maxInitialLineLength}} and {{maxChunkSize}} which might
be necessary to be configured here are not exposed but would be good if so.
Patch is already available:
https://github.com/micfra/camel/tree/camel-netty-http-ext-configuration - Pull
request follows.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18476) when artemis streaming enabled then Camel-jms component is not closing inputstream for Bytes message, blocking deletion of file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramarajan R updated CAMEL-18476:
Summary: when artemis streaming enabled then Camel-jms component is not
closing inputstream for Bytes message, blocking deletion of file after its
archived in windows (was: when artemis streaming enabled then Camel-jms
component is not closing inputstream, blocking deletion of file after its
archived in windows)
> when artemis streaming enabled then Camel-jms component is not closing
> inputstream for Bytes message, blocking deletion of file after its archived
> in windows
> -
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
> {{[https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-file.20artemis.20large.20message.20example.20failing.20in.20windows]
> }}{{{}tion-poc/inbox0] o.a.c.c.file.GenericFileOnCompletion : Error during
> commit. Exchange[7D4CFE29E3F7515-0003]. Caused by:
> [org.apache.camel.component.file.GenericFileOperationFailedException - Error
> renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx to
> C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx]{}}}{{{}org.apache.camel.component.file.GenericFileOperationFailedException:
> Error renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx
> to C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx{}}}
> {{at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:93)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:145)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:121)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:134)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:60)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronization(UnitOfWorkHelper.java:104)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:93)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultUnitOfWork.done(DefaultUnitOfWork.java:238)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:61)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:777)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:712)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:263)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
>
[jira] [Updated] (CAMEL-18476) when artemis streaming enabled then Camel-jms component is not closing inputstream, blocking deletion of file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramarajan R updated CAMEL-18476:
Summary: when artemis streaming enabled then Camel-jms component is not
closing inputstream, blocking deletion of file after its archived in windows
(was: when artemis streaming enabled then Camel-jms component is not closing
inputstream able to delete the file after its archived in windows)
> when artemis streaming enabled then Camel-jms component is not closing
> inputstream, blocking deletion of file after its archived in windows
> ---
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
> {{[https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-file.20artemis.20large.20message.20example.20failing.20in.20windows]
> }}{{{}tion-poc/inbox0] o.a.c.c.file.GenericFileOnCompletion : Error during
> commit. Exchange[7D4CFE29E3F7515-0003]. Caused by:
> [org.apache.camel.component.file.GenericFileOperationFailedException - Error
> renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx to
> C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx]{}}}{{{}org.apache.camel.component.file.GenericFileOperationFailedException:
> Error renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx
> to C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx{}}}
> {{at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:93)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:145)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:121)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:134)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:60)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronization(UnitOfWorkHelper.java:104)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:93)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultUnitOfWork.done(DefaultUnitOfWork.java:238)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:61)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:777)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:712)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:263)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
> ~[camel-core-processor-3.14.3.jar:3.14.3]}}
> {{at
>
[jira] [Updated] (CAMEL-18476) when artemis streaming enabled then Camel-jms component is not closing inputstream able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramarajan R updated CAMEL-18476:
Summary: when artemis streaming enabled then Camel-jms component is not
closing inputstream able to delete the file after its archived in windows
(was: when artemis streaming enabled then Camel-jms component is not able to
delete the file after its archived in windows)
> when artemis streaming enabled then Camel-jms component is not closing
> inputstream able to delete the file after its archived in windows
>
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
> {{[https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-file.20artemis.20large.20message.20example.20failing.20in.20windows]
> }}{{{}tion-poc/inbox0] o.a.c.c.file.GenericFileOnCompletion : Error during
> commit. Exchange[7D4CFE29E3F7515-0003]. Caused by:
> [org.apache.camel.component.file.GenericFileOperationFailedException - Error
> renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx to
> C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx]{}}}{{{}org.apache.camel.component.file.GenericFileOperationFailedException:
> Error renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx
> to C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx{}}}
> {{at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:93)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:145)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:121)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:134)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:60)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronization(UnitOfWorkHelper.java:104)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:93)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultUnitOfWork.done(DefaultUnitOfWork.java:238)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:61)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:777)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:712)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:263)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
> ~[camel-core-processor-3.14.3.jar:3.14.3]}}
> {{at
>
[jira] [Updated] (CAMEL-18476) when artemis streaming enabled then Camel-jms component is not able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramarajan R updated CAMEL-18476:
Component/s: camel-jms
(was: camel-file)
> when artemis streaming enabled then Camel-jms component is not able to delete
> the file after its archived in windows
>
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-jms
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
> {{[https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-file.20artemis.20large.20message.20example.20failing.20in.20windows]
> }}{{{}tion-poc/inbox0] o.a.c.c.file.GenericFileOnCompletion : Error during
> commit. Exchange[7D4CFE29E3F7515-0003]. Caused by:
> [org.apache.camel.component.file.GenericFileOperationFailedException - Error
> renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx to
> C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx]{}}}{{{}org.apache.camel.component.file.GenericFileOperationFailedException:
> Error renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx
> to C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx{}}}
> {{at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:93)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:145)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:121)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:134)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:60)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronization(UnitOfWorkHelper.java:104)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:93)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultUnitOfWork.done(DefaultUnitOfWork.java:238)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:61)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:777)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:712)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:263)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
> ~[camel-core-processor-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:398)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:492)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
>
[jira] [Updated] (CAMEL-18476) when artemis streaming enabled then Camel-jms component is not able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramarajan R updated CAMEL-18476:
Summary: when artemis streaming enabled then Camel-jms component is not
able to delete the file after its archived in windows (was: when artemis
streaming enabled then Camel-file component is not able to delete the file
after its archived in windows)
> when artemis streaming enabled then Camel-jms component is not able to delete
> the file after its archived in windows
>
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
> {{[https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-file.20artemis.20large.20message.20example.20failing.20in.20windows]
> }}{{{}tion-poc/inbox0] o.a.c.c.file.GenericFileOnCompletion : Error during
> commit. Exchange[7D4CFE29E3F7515-0003]. Caused by:
> [org.apache.camel.component.file.GenericFileOperationFailedException - Error
> renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx to
> C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx]{}}}{{{}org.apache.camel.component.file.GenericFileOperationFailedException:
> Error renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx
> to C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx{}}}
> {{at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:93)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:145)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:121)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:134)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:60)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronization(UnitOfWorkHelper.java:104)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:93)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultUnitOfWork.done(DefaultUnitOfWork.java:238)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:61)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:777)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:712)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:263)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
> ~[camel-core-processor-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:398)
>
[jira] [Resolved] (CAMEL-18466) Camel-AWS2-SQS: Move from ComponentVerifierExtension to HealtCheck
[ https://issues.apache.org/jira/browse/CAMEL-18466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-18466. -- Resolution: Fixed > Camel-AWS2-SQS: Move from ComponentVerifierExtension to HealtCheck > -- > > Key: CAMEL-18466 > URL: https://issues.apache.org/jira/browse/CAMEL-18466 > Project: Camel > Issue Type: Improvement > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602301#comment-17602301
]
Andrea Cosentino commented on CAMEL-18492:
--
So maybe we should make it configurable and set to true by default. [~davsclaus]
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Major
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602300#comment-17602300
]
Andrea Cosentino commented on CAMEL-18492:
--
As a side note even Michael Kay comments about this on Stack Overflow that this
feature is widely misunderstood
https://stackoverflow.com/questions/51378748/extension-functions-cannot-be-used-when-secure-feature-proccesing-is-set-to-true
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Major
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602297#comment-17602297
]
Andrea Cosentino edited comment on CAMEL-18492 at 9/9/22 12:08 PM:
---
It's a security best practice to the set FEATURE_SECURE_PROCESSING property to
true.
was (Author: ancosen):
It's a security best practice to the FEATURE_SECURE_PROCESSING to true.
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Major
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602297#comment-17602297
]
Andrea Cosentino commented on CAMEL-18492:
--
It's a security best practice to the FEATURE_SECURE_PROCESSING to true.
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Major
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
[
https://issues.apache.org/jira/browse/CAMEL-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harish Annamalai updated CAMEL-18492:
-
Priority: Major (was: Minor)
> Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
> --
>
> Key: CAMEL-18492
> URL: https://issues.apache.org/jira/browse/CAMEL-18492
> Project: Camel
> Issue Type: Bug
> Components: camel-saxon, camel-xslt
>Affects Versions: 3.0.0
>Reporter: Harish Annamalai
>Priority: Major
>
> Hi All,
> We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
> 9.9.1.6.
> We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
> exact).
> We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
> Transformations.
> We also *Extension Functions,* which we pass to camel-xslt-saxon component.
> What we have observed in camel 3.x versions and above, In class
> {{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
> functions, at line 202, {{registerSaxonExtensionFunctions}} method of
> {{{*}XsltSaxonHelper{*}.java}} is called.
>
> In XsltSaxonHelper.class, the method,
> {{{}registerSaxonExtensionFunctions{}}}, at line 55, sets a feature of
> {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
> Unfortunately, Setting this Feature disables the External Java Function
> calls.
> We checked in Camel 2.x versions, this Feature is not set and therefore the
> External Java Calls work fine.
>
> We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING*
> is being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
>
> Sample Code to test:
> {{import javax.xml.XMLConstants;}}
> {{import javax.xml.transform.Transformer;}}
> {{import javax.xml.transform.TransformerException;}}
> {{import javax.xml.transform.TransformerFactory;}}
> {{import javax.xml.transform.stream.StreamResult;}}
> {{import javax.xml.transform.stream.StreamSource;}}
> {{import java.io.File;}}
> {{public class SaxonTransformationTester {}}
> {{ public static void main(String[] args) throws TransformerException {}}
> {{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
> {{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
> {{ EnterpriseTransformerFactory eef =
> SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
> {{
> eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
> {{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This
> causes External Functions to break}}
> {{
> eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
> false);}}
> {{ Transformer transformer = eef.newTransformer(new StreamSource(}}
> {{ new File(foo_xsl)));}}
> {{ transformer.transform(new StreamSource(new File(foo_xml)),}}
> {{ new StreamResult(System.out));}}
> {{ }}}
> {{}}}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18492) Enterprise Feature of Saxon is Disabled in Camel 3.x versions.
Harish Annamalai created CAMEL-18492:
Summary: Enterprise Feature of Saxon is Disabled in Camel 3.x
versions.
Key: CAMEL-18492
URL: https://issues.apache.org/jira/browse/CAMEL-18492
Project: Camel
Issue Type: Bug
Components: camel-saxon, camel-xslt
Affects Versions: 3.0.0
Reporter: Harish Annamalai
Hi All,
We use Camel-Saxon for one of our product. We use Saxon Enterprise Edition
9.9.1.6.
We are migrating our product from camel 2.x to camel 3.x (2.24 to 3.15 to be
exact).
We use a paid feature of Saxon; Invoking *External Java Functions* in XSL
Transformations.
We also *Extension Functions,* which we pass to camel-xslt-saxon component.
What we have observed in camel 3.x versions and above, In class
{{{*}XsltSaxonEndpoint{*}.java}} During the registration of extension
functions, at line 202, {{registerSaxonExtensionFunctions}} method of
{{{*}XsltSaxonHelper{*}.java}} is called.
In XsltSaxonHelper.class, the method, {{{}registerSaxonExtensionFunctions{}}},
at line 55, sets a feature of {*}XMLConstants.FEATURE_SECURE_PROCESSING{*}.
Unfortunately, Setting this Feature disables the External Java Function calls.
We checked in Camel 2.x versions, this Feature is not set and therefore the
External Java Calls work fine.
We see this as a bug - The Feature *XMLConstants.FEATURE_SECURE_PROCESSING* is
being introduced in 3.x and breaks a paid/Enterprise feature of Saxon.
Sample Code to test:
{{import javax.xml.XMLConstants;}}
{{import javax.xml.transform.Transformer;}}
{{import javax.xml.transform.TransformerException;}}
{{import javax.xml.transform.TransformerFactory;}}
{{import javax.xml.transform.stream.StreamResult;}}
{{import javax.xml.transform.stream.StreamSource;}}
{{import java.io.File;}}
{{public class SaxonTransformationTester {}}
{{ public static void main(String[] args) throws TransformerException {}}
{{ String foo_xml = "src/main/resources/in.xml"; // input xml}}
{{ String foo_xsl = "src/main/resources/transf.xml"; // input xsl}}
{{ EnterpriseTransformerFactory eef =
SaxonEEConsumerFactory.getEnterpriseTransformerFactoryInstance();}}
{{
eef.getConfiguration().getConfigurationProperty(Feature.ALLOW_EXTERNAL_FUNCTIONS);}}
{{ eef.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); //This causes
External Functions to break}}
{{
eef.getConfiguration().setConfigurationProperty("http://saxon.sf.net/feature/trace-external-functions;,
false);}}
{{ Transformer transformer = eef.newTransformer(new StreamSource(}}
{{ new File(foo_xsl)));}}
{{ transformer.transform(new StreamSource(new File(foo_xml)),}}
{{ new StreamResult(System.out));}}
{{ }}}
{{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18491) camel-main - Configuring vault should avoid reflection
Claus Ibsen created CAMEL-18491: --- Summary: camel-main - Configuring vault should avoid reflection Key: CAMEL-18491 URL: https://issues.apache.org/jira/browse/CAMEL-18491 Project: Camel Issue Type: Improvement Components: camel-main Reporter: Claus Ibsen Fix For: 3.19.0 I noticed in the aws secret reloader example that the bean introspector reports that reflection are used for configuring the vault options. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18451) camel-azure-eventhubs: Add support for Azure-AD authentication
[ https://issues.apache.org/jira/browse/CAMEL-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602283#comment-17602283 ] Claus Ibsen commented on CAMEL-18451: - I think camel-karaf needs to be updated too, as it has a feature for azure so it needs to have the new JARs added. > camel-azure-eventhubs: Add support for Azure-AD authentication > -- > > Key: CAMEL-18451 > URL: https://issues.apache.org/jira/browse/CAMEL-18451 > Project: Camel > Issue Type: Improvement > Components: camel-azure-eventhubs >Affects Versions: 3.18.1 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18451) camel-azure-eventhubs: Add support for Azure-AD authentication
[ https://issues.apache.org/jira/browse/CAMEL-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18451: Issue Type: New Feature (was: Improvement) > camel-azure-eventhubs: Add support for Azure-AD authentication > -- > > Key: CAMEL-18451 > URL: https://issues.apache.org/jira/browse/CAMEL-18451 > Project: Camel > Issue Type: New Feature > Components: camel-azure-eventhubs >Affects Versions: 3.18.1 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18490) camel-jbang - Reset statistics can cause inflight counter to be negative
[
https://issues.apache.org/jira/browse/CAMEL-18490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18490:
Description:
{code}
PID NAME CAMELPLATFORM READY STATUS RELOAD AGE ROUTE
MSG/S TOTAL FAIL INFLIGHT SINCE-LAST
88183 foo 3.19.0-SNAPSHOT JBang 1/1 Running 1 1m59s1/1
7.97538 0-1 0s/0s/-
{code}
was:
PID NAME CAMELPLATFORM READY STATUS RELOAD AGE ROUTE
MSG/S TOTAL FAIL INFLIGHT SINCE-LAST
88183 foo 3.19.0-SNAPSHOT JBang 1/1 Running 1 1m59s1/1
7.97538 0-1 0s/0s/-
> camel-jbang - Reset statistics can cause inflight counter to be negative
>
>
> Key: CAMEL-18490
> URL: https://issues.apache.org/jira/browse/CAMEL-18490
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.19.0
>
>
> {code}
> PID NAME CAMELPLATFORM READY STATUS RELOAD AGE ROUTE
> MSG/S TOTAL FAIL INFLIGHT SINCE-LAST
> 88183 foo 3.19.0-SNAPSHOT JBang 1/1 Running 1 1m59s1/1
> 7.97538 0-1 0s/0s/-
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18490) camel-jbang - Reset statistics can cause inflight counter to be negative
Claus Ibsen created CAMEL-18490: --- Summary: camel-jbang - Reset statistics can cause inflight counter to be negative Key: CAMEL-18490 URL: https://issues.apache.org/jira/browse/CAMEL-18490 Project: Camel Issue Type: Bug Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.19.0 PID NAME CAMELPLATFORM READY STATUS RELOAD AGE ROUTE MSG/S TOTAL FAIL INFLIGHT SINCE-LAST 88183 foo 3.19.0-SNAPSHOT JBang 1/1 Running 1 1m59s1/1 7.97538 0-1 0s/0s/- -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18451) camel-azure-eventhubs: Add support for Azure-AD authentication
[ https://issues.apache.org/jira/browse/CAMEL-18451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602277#comment-17602277 ] Babak Vahdat commented on CAMEL-18451: -- [~davsclaus] can we backport this feature to the 3.18.x LTS branch? If so I would then provide the corresponding PR for that. > camel-azure-eventhubs: Add support for Azure-AD authentication > -- > > Key: CAMEL-18451 > URL: https://issues.apache.org/jira/browse/CAMEL-18451 > Project: Camel > Issue Type: Improvement > Components: camel-azure-eventhubs >Affects Versions: 3.18.1 >Reporter: Babak Vahdat >Assignee: Babak Vahdat >Priority: Minor > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18489) camel-file - Exclusive rename should handle windows locking the file
[ https://issues.apache.org/jira/browse/CAMEL-18489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18489. - Resolution: Fixed > camel-file - Exclusive rename should handle windows locking the file > > > Key: CAMEL-18489 > URL: https://issues.apache.org/jira/browse/CAMEL-18489 > Project: Camel > Issue Type: Bug > Components: camel-file >Affects Versions: 3.18.0 >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.18.3, 3.19.0 > > > https://github.com/apache/camel/pull/8335 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18489) camel-file - Exclusive rename should handle windows locking the file
Claus Ibsen created CAMEL-18489: --- Summary: camel-file - Exclusive rename should handle windows locking the file Key: CAMEL-18489 URL: https://issues.apache.org/jira/browse/CAMEL-18489 Project: Camel Issue Type: Bug Components: camel-file Affects Versions: 3.18.0 Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.18.3, 3.19.0 https://github.com/apache/camel/pull/8335 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18476) when artemis streaming enabled then Camel-file component is not able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602271#comment-17602271
]
Ramarajan R edited comment on CAMEL-18476 at 9/9/22 11:21 AM:
--
Hi [~davsclaus]
In JmsBinding.class Input stream is not closed for bytes message type @ Line
number 657 where as for type Stream input stream is closed. @Line number 725
Thanks,
R Ramarajan.
was (Author: ramarajan):
Hi [~davsclaus]
In JmsBinding.class Input stream is not closed for bytes message type where as
for type Stream input stream is closed.
case Bytes: {
BytesMessage message = session.createBytesMessage();
if (body != null) {
try {
if (endpoint.isArtemisStreamingEnabled())
{ LOG.trace("Optimised for Artemis: Streaming
payload in BytesMessage"); _InputStream is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);_
_message.setObjectProperty("JMS_AMQ_InputStream", is);_
_LOG.trace("Optimised for Artemis: Finished streaming payload in
BytesMessage");_ }
else
{ byte[] payload =
context.getTypeConverter().mandatoryConvertTo(byte[].class, exchange, body);
message.writeBytes(payload); }
} catch (NoTypeConversionAvailableException e)
{ // cannot convert to inputstream then thrown an
exception to avoid sending a null message JMSException
cause = new MessageFormatException(e.getMessage());
cause.initCause(e); throw cause; }
}
return message;
}
case Stream: {
StreamMessage message = session.createStreamMessage();
if (body != null) {
long size = 0;
InputStream is = null;
try {
is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);
LOG.trace("Writing payload in StreamMessage");
// assume streaming is bigger payload so use same
buffer size as the file component
byte[] buffer = new byte[FileUtil.BUFFER_SIZE];
int len = 0;
int count = 0;
while (len >= 0) {
count++;
len = is.read(buffer);
if (len >= 0) {
size += len;
LOG.trace("Writing payload chunk {} as bytes in
StreamMessage", count);
message.writeBytes(buffer, 0, len);
}
}
LOG.trace("Finished writing payload (size {}) as bytes
in StreamMessage", size);
} catch (NoTypeConversionAvailableException | IOException
e) \{ // cannot convert to inputstream then thrown an
exception to avoid sending a null message JMSException
cause = new MessageFormatException(e.getMessage());
cause.initCause(e); throw cause; }
finally
{ *IOHelper.close(is);* }
}
return message;
}
> when artemis streaming enabled then Camel-file component is not able to
> delete the file after its archived in windows
> -
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
>
[jira] [Comment Edited] (CAMEL-18476) when artemis streaming enabled then Camel-file component is not able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602271#comment-17602271
]
Ramarajan R edited comment on CAMEL-18476 at 9/9/22 11:19 AM:
--
Hi [~davsclaus]
In JmsBinding.class Input stream is not closed for bytes message type where as
for type Stream input stream is closed.
case Bytes: {
BytesMessage message = session.createBytesMessage();
if (body != null) {
try {
if (endpoint.isArtemisStreamingEnabled())
{ LOG.trace("Optimised for Artemis: Streaming
payload in BytesMessage"); _InputStream is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);_
_message.setObjectProperty("JMS_AMQ_InputStream", is);_
_LOG.trace("Optimised for Artemis: Finished streaming payload in
BytesMessage");_ }
else
{ byte[] payload =
context.getTypeConverter().mandatoryConvertTo(byte[].class, exchange, body);
message.writeBytes(payload); }
} catch (NoTypeConversionAvailableException e)
{ // cannot convert to inputstream then thrown an
exception to avoid sending a null message JMSException
cause = new MessageFormatException(e.getMessage());
cause.initCause(e); throw cause; }
}
return message;
}
case Stream: {
StreamMessage message = session.createStreamMessage();
if (body != null) {
long size = 0;
InputStream is = null;
try {
is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);
LOG.trace("Writing payload in StreamMessage");
// assume streaming is bigger payload so use same
buffer size as the file component
byte[] buffer = new byte[FileUtil.BUFFER_SIZE];
int len = 0;
int count = 0;
while (len >= 0) {
count++;
len = is.read(buffer);
if (len >= 0) {
size += len;
LOG.trace("Writing payload chunk {} as bytes in
StreamMessage", count);
message.writeBytes(buffer, 0, len);
}
}
LOG.trace("Finished writing payload (size {}) as bytes
in StreamMessage", size);
} catch (NoTypeConversionAvailableException | IOException
e) \{ // cannot convert to inputstream then thrown an
exception to avoid sending a null message JMSException
cause = new MessageFormatException(e.getMessage());
cause.initCause(e); throw cause; }
finally
{ *IOHelper.close(is);* }
}
return message;
}
was (Author: ramarajan):
Hi [~davsclaus]
In JmsBinding.class Input stream is not closed for bytes message type where as
for type Stream input stream is closed.
case Bytes: {
BytesMessage message = session.createBytesMessage();
if (body != null) {
try {
if (endpoint.isArtemisStreamingEnabled()) {
LOG.trace("Optimised for Artemis: Streaming payload
in BytesMessage");
_InputStream is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);_
_message.setObjectProperty("JMS_AMQ_InputStream",
is);_
_LOG.trace("Optimised for Artemis: Finished
streaming payload in BytesMessage");_
} else {
byte[] payload =
context.getTypeConverter().mandatoryConvertTo(byte[].class, exchange, body);
message.writeBytes(payload);
}
} catch (NoTypeConversionAvailableException e) {
// cannot convert to inputstream then thrown an
exception to avoid sending a null message
JMSException cause = new
MessageFormatException(e.getMessage());
cause.initCause(e);
throw cause;
}
}
[jira] [Commented] (CAMEL-18476) when artemis streaming enabled then Camel-file component is not able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602271#comment-17602271
]
Ramarajan R commented on CAMEL-18476:
-
Hi [~davsclaus]
In JmsBinding.class Input stream is not closed for bytes message type where as
for type Stream input stream is closed.
case Bytes: {
BytesMessage message = session.createBytesMessage();
if (body != null) {
try {
if (endpoint.isArtemisStreamingEnabled()) {
LOG.trace("Optimised for Artemis: Streaming payload
in BytesMessage");
_InputStream is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);_
_message.setObjectProperty("JMS_AMQ_InputStream",
is);_
_LOG.trace("Optimised for Artemis: Finished
streaming payload in BytesMessage");_
} else {
byte[] payload =
context.getTypeConverter().mandatoryConvertTo(byte[].class, exchange, body);
message.writeBytes(payload);
}
} catch (NoTypeConversionAvailableException e) {
// cannot convert to inputstream then thrown an
exception to avoid sending a null message
JMSException cause = new
MessageFormatException(e.getMessage());
cause.initCause(e);
throw cause;
}
}
return message;
}
case Map: {
MapMessage message = session.createMapMessage();
if (body != null) {
Map payload =
context.getTypeConverter().convertTo(Map.class, exchange, body);
populateMapMessage(message, payload, context);
}
return message;
}
case Object: {
ObjectMessage message = session.createObjectMessage();
if (body != null) {
try {
Serializable payload
=
context.getTypeConverter().mandatoryConvertTo(Serializable.class, exchange,
body);
message.setObject(payload);
} catch (NoTypeConversionAvailableException e) {
// cannot convert to serializable then thrown an
exception to avoid sending a null message
JMSException cause = new
MessageFormatException(e.getMessage());
cause.initCause(e);
throw cause;
}
}
return message;
}
case Stream: {
StreamMessage message = session.createStreamMessage();
if (body != null) {
long size = 0;
InputStream is = null;
try {
is =
context.getTypeConverter().mandatoryConvertTo(InputStream.class, exchange,
body);
LOG.trace("Writing payload in StreamMessage");
// assume streaming is bigger payload so use same
buffer size as the file component
byte[] buffer = new byte[FileUtil.BUFFER_SIZE];
int len = 0;
int count = 0;
while (len >= 0) {
count++;
len = is.read(buffer);
if (len >= 0) {
size += len;
LOG.trace("Writing payload chunk {} as bytes in
StreamMessage", count);
message.writeBytes(buffer, 0, len);
}
}
LOG.trace("Finished writing payload (size {}) as bytes
in StreamMessage", size);
} catch (NoTypeConversionAvailableException | IOException
e) {
// cannot convert to inputstream then thrown an
exception to avoid sending a null message
JMSException cause = new
MessageFormatException(e.getMessage());
cause.initCause(e);
throw cause;
} finally {
*IOHelper.close(is);*
}
}
return message;
}
> when artemis streaming enabled then Camel-file component is not able to
> delete the file after its archived in windows
> -
>
> Key: CAMEL-18476
> URL:
[jira] [Commented] (CAMEL-18476) when artemis streaming enabled then Camel-file component is not able to delete the file after its archived in windows
[
https://issues.apache.org/jira/browse/CAMEL-18476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602264#comment-17602264
]
Ramarajan R commented on CAMEL-18476:
-
Hi Team,
Adding JMS Message type as Stream solves the issue,
jms:queue:data{*}?jmsMessageType=Stream{*}
Tried with Bytes its not working
Thanks,
R Ramarajan.
> when artemis streaming enabled then Camel-file component is not able to
> delete the file after its archived in windows
> -
>
> Key: CAMEL-18476
> URL: https://issues.apache.org/jira/browse/CAMEL-18476
> Project: Camel
> Issue Type: Bug
> Components: camel-file
>Affects Versions: 3.14.3, 3.18.1
>Reporter: Ramarajan R
>Priority: Minor
> Attachments: artemis-large-messages-final.zip,
> artemis-large-messages.zip
>
>
> I have used
> [https://github.com/apache/camel-examples/tree/main/examples/artemis-large-messages]
> using AMQ 7.8.0 Broker
> Messages are getting processed but after processing the file is unable to
> delete from source location, tested in more than 1 windows systems facing the
> same
> I am using Camel 3.14.3 and Spring boot 2.6.6 using JAVA DSL,
> tested with Camel 3.18.1 and Spring boot 2.7.3 also
> when running with Camel XML routes are fine but we want to use Java DSL ,
> Kindly help.
> Raising the concern in Zulip chat earlier.
> {{[https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/camel-file.20artemis.20large.20message.20example.20failing.20in.20windows]
> }}{{{}tion-poc/inbox0] o.a.c.c.file.GenericFileOnCompletion : Error during
> commit. Exchange[7D4CFE29E3F7515-0003]. Caused by:
> [org.apache.camel.component.file.GenericFileOperationFailedException - Error
> renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx to
> C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx]{}}}{{{}org.apache.camel.component.file.GenericFileOperationFailedException:
> Error renaming file from C:\opt\file-transfer-solution-poc\inbox0\test.xlsx
> to C:\opt\file-transfer-solution-poc\inbox0\.camel\test.xlsx{}}}
> {{at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:93)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:145)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:121)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:134)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:86)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:60)
> ~[camel-file-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronization(UnitOfWorkHelper.java:104)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:93)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultUnitOfWork.done(DefaultUnitOfWork.java:238)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.support.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:61)
> ~[camel-support-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:777)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:712)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor$AsyncAfterTask.done(CamelInternalProcessor.java:263)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.AsyncCallback.run(AsyncCallback.java:44)
> ~[camel-api-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor$Worker.schedule(DefaultReactiveExecutor.java:193)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.DefaultReactiveExecutor.scheduleMain(DefaultReactiveExecutor.java:64)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at org.apache.camel.processor.Pipeline.process(Pipeline.java:184)
> ~[camel-core-processor-3.14.3.jar:3.14.3]}}
> {{at
> org.apache.camel.impl.engine.CamelInternalProcessor.process(CamelInternalProcessor.java:398)
> ~[camel-base-engine-3.14.3.jar:3.14.3]}}
> {{at
>
[jira] [Commented] (CAMEL-14680) javax -> jakarta
[ https://issues.apache.org/jira/browse/CAMEL-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17602246#comment-17602246 ] Jimisola Laursen commented on CAMEL-14680: -- We are currently using Spring Boot 3.0.0-Mx due to features that we want but it integrates poorly with current version of Camel due the the Java 17 runtime support only. . We would like to continue to use Camel. I checked https://issues.apache.org/jira/browse/CAMEL-11567 as well but no information there. Any information on when Camel will support Jakarta EE? Will Camel do as Spring etc and require 17? > javax -> jakarta > > > Key: CAMEL-14680 > URL: https://issues.apache.org/jira/browse/CAMEL-14680 > Project: Camel > Issue Type: Task >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > When the industry switches from javax to jarkarta then we should follow up as > well. > Its mostly JMS, Servlet, Mail, CDI, WS, JAX-RS, and other components. So at > some day we may have a release that switches fully over and is not backwards > compatible. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-13436) Set TLS default to TLSv1.3 once we move to JDK11
[ https://issues.apache.org/jira/browse/CAMEL-13436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-13436: --- Assignee: Claus Ibsen > Set TLS default to TLSv1.3 once we move to JDK11 > - > > Key: CAMEL-13436 > URL: https://issues.apache.org/jira/browse/CAMEL-13436 > Project: Camel > Issue Type: Improvement > Components: camel-core, camel-http, camel-jetty, camel-restlet, > camel-solr >Affects Versions: 3.0.0 >Reporter: John Poth >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.19.0 > > > Also add tests to different components that use TLS > http://openjdk.java.net/jeps/332 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17652) camel-minio - Auto create bucket should not be done in endpoint
[ https://issues.apache.org/jira/browse/CAMEL-17652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17652: Fix Version/s: 3.20.0 (was: 3.19.0) > camel-minio - Auto create bucket should not be done in endpoint > --- > > Key: CAMEL-17652 > URL: https://issues.apache.org/jira/browse/CAMEL-17652 > Project: Camel > Issue Type: Improvement > Components: camel-minio >Reporter: Claus Ibsen >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.20.0 > > > https://ci-builds.apache.org/job/Camel/job/Apache%20Camel/job/main/108/testReport/junit/org.apache.camel.component.minio.integration/MinioConsumerIT/sendIn/ > If the bucket cannot be created such as minio service is unavailable (http > status 503) then the endpoint fails and camel fails to start. > The consumer already have logic for auto-create in its start method, which > you can configure to keep restarting the route on failure with the route > controller. > I am not sure if the producer needs this as the operations are get / list etc > - and whether they would fail if bucket does not exist - then this logic > needs to be moved to the producer also -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18469) camel-main - Configure vault/cloud secrets reloader and auto detect via classpath
[ https://issues.apache.org/jira/browse/CAMEL-18469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18469. - Assignee: Claus Ibsen Resolution: Fixed > camel-main - Configure vault/cloud secrets reloader and auto detect via > classpath > - > > Key: CAMEL-18469 > URL: https://issues.apache.org/jira/browse/CAMEL-18469 > Project: Camel > Issue Type: Sub-task > Components: camel-main >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.19.0 > > > So you can turn this on|off and set some options on the secrets updated > checker. > And be able to auto-detect it via classpath and setup into CamelContext -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18484) Camel-xchange: Enable mock testing without neaed of real account
[
https://issues.apache.org/jira/browse/CAMEL-18484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18484:
Fix Version/s: 3.19.0
> Camel-xchange: Enable mock testing without neaed of real account
>
>
> Key: CAMEL-18484
> URL: https://issues.apache.org/jira/browse/CAMEL-18484
> Project: Camel
> Issue Type: Test
>Affects Versions: 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Major
> Fix For: 3.19.0
>
>
> Tests in camel-xchange component are disabled by default (because of the need
> of the real credentials)
> {code:java}
> @EnabledIfSystemProperty(named = "enable.xchange.itests", matches = "true",
> disabledReason = "Requires API credentials") {code}
> It would be much better if the functionality was covered by mocked junit
> tests. (For example wiremock could be used)
> - if _enable.xchange.itests_ is set to {_}true{_}, not-mocked test would be
> used (as before)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18488) camel-management - Statistic for current throughput
[ https://issues.apache.org/jira/browse/CAMEL-18488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18488. - Resolution: Fixed > camel-management - Statistic for current throughput > --- > > Key: CAMEL-18488 > URL: https://issues.apache.org/jira/browse/CAMEL-18488 > Project: Camel > Issue Type: New Feature > Components: camel-jmx >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.19.0 > > > If you enable load average then we can also output the current msg/sec as > throughput. > And maybe also calculate a sliding window of average throughput. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (CAMEL-18454) Support Secrets Reload from Vault/Cloud Service through specific Tasks in components
[ https://issues.apache.org/jira/browse/CAMEL-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino reopened CAMEL-18454: -- > Support Secrets Reload from Vault/Cloud Service through specific Tasks in > components > > > Key: CAMEL-18454 > URL: https://issues.apache.org/jira/browse/CAMEL-18454 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.19.0 > > > We have some example of tasks for having a secret reload based on events in > the camel-examples repo. > We should try to do this for all the vault/cloud services we are supporting. > As far as I know Hashicorp Vault doesn't have a notification system for this > purpose, but I need to dig a bit. > List of components to support > - Camel-AWS-secrets-manager > - Camel-google-secrets-manager > - Camel-Azure-Key-vault > and maybe Camel-Hashicorp Vault -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18454) Support Secrets Reload from Vault/Cloud Service through specific Tasks in components
[ https://issues.apache.org/jira/browse/CAMEL-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-18454. -- Resolution: Fixed > Support Secrets Reload from Vault/Cloud Service through specific Tasks in > components > > > Key: CAMEL-18454 > URL: https://issues.apache.org/jira/browse/CAMEL-18454 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.19.0 > > > We have some example of tasks for having a secret reload based on events in > the camel-examples repo. > We should try to do this for all the vault/cloud services we are supporting. > As far as I know Hashicorp Vault doesn't have a notification system for this > purpose, but I need to dig a bit. > List of components to support > - Camel-AWS-secrets-manager > - Camel-google-secrets-manager > - Camel-Azure-Key-vault > and maybe Camel-Hashicorp Vault -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18487) Camel-AWS-Secrets-Manager: Cloudtrail task should support environment variables as configuration too
[ https://issues.apache.org/jira/browse/CAMEL-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-18487. -- Resolution: Fixed > Camel-AWS-Secrets-Manager: Cloudtrail task should support environment > variables as configuration too > > > Key: CAMEL-18487 > URL: https://issues.apache.org/jira/browse/CAMEL-18487 > Project: Camel > Issue Type: Sub-task > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
