You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Guillaume Nodet (Jira)" <ji...@apache.org> on 2026/07/27 13:53:00 UTC

[jira] [Work started] (CAMEL-24216) jdk.xml.xpathTotalOpLimit can be overriden and is not set back correctly after execution

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

Work on CAMEL-24216 started by Guillaume Nodet.
-----------------------------------------------
> jdk.xml.xpathTotalOpLimit can be overriden and is not set back correctly after execution
> ----------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24216
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24216
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-xslt
>    Affects Versions: 4.21.0
>            Reporter: Aurélien Pupier
>            Assignee: Guillaume Nodet
>            Priority: Minor
>
> org.apache.camel.component.xslt.XsltComponent.setXpathTotalOpLimit(int) allows to configure jdk.xml.xpathTotalOpLimit
> this is setting through a ssytem property in doInit()
> The value is cleared in doShutdown
> The doShutdown is nto called during test execution of ZXsltTotalOpsTest causing potentially other tests to fail. it is sometimes the case for XsltFromFileExceptionTest when thsi one is falky and failed a first time, because the retries occurs after all tests, and so after ZXsltTotalOpsTest
> also we should:
> * store previous value of jdk.xml.xpathTotalOpLimit to restore it instead of clearing it
> * provide some logging in case a value was already set?
> * do not allow to execute concurrent xslt component when the xpathTotalOpLimit is configured differently
> * provide a more fine-grained configuration so that the lifecycle is not stepping on other executions



--
This message was sent by Atlassian Jira
(v8.20.10#820010)