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)