[jboss-jira] [JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

[Jason Greene (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409136#comment-13409136 ] 

Jason Greene edited comment on WFCORE-2805 at 5/19/17 11:06 AM:
----------------------------------------------------------------

Theres a few more cases that need investigation:

1) Translet class loading is modular compatible - see https://issues.apache.org/jira/browse/XALANJ-2535

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

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

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. 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.  




was (Author: jason.greene):
Theres a few more cases that need investigation:

1) Translet class loading is modular compatible - see https://issues.apache.org/jira/browse/XALANJ-2535
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
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
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. 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.  



> Use Xalan from JRE rather than our own fork
> -------------------------------------------
>
>                 Key: WFCORE-2805
>                 URL: https://issues.jboss.org/browse/WFCORE-2805
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)