[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] Peter Palaga commented on WFCORE-2805: -------------------------------------- Thanks Jason, bq. 1) Translet class loading is modular compatible - see https://issues.apache.org/jira/browse/XALANJ-2535 I'd say the [XsltClassLoadingTestCase|https://github.com/ppalaga/wildfly/commit/e8c21f...] and its [transform.xsl|https://github.com/ppalaga/wildfly/commit/e8c21f47cfec3f862...] prove exactly what you require - that both classes from the transfromer impl as well as user code (xsltc java external functions) can be loaded from one translet. bq. 2) Deployments can bundle their own version of a JAXP transformer impl (xalan, saxon, etc) Three deployments A, B, and C . A and B bundle different implies, and C does not. Verify the expected impl is chosen correctly Will do. bq. 3) Modules obtain a different JAXP impl via a dependency. Create a custom module for a special JAXP transformer impl (xalan, saxon, etc) Add a dependency on a module which defines a service. Verify the service gets the correct JAXP transformer impl Yes, let me try this. bq. 4) Investigate how we carry over the ability to set a container wide default JAXP impl. Currently a user can replace the transformer with any version they choose. What is the user currently supposed to do to change the container wide default JAXP impl? bq. We have special JAXP redirection facilities to ensure that any JAXP impl which they may choose becomes the new container default. This was necessary in the past because of limitation in the JAXP search logic, which relied on hierarchical searching, and if a cl search failed would fall back to the wrong hard coded class names, as opposed to a META-INF/services search against the JVM. -- This message was sent by Atlassian JIRA (v7.2.3#72005)