[jira] [Closed] (SANTUARIO-358) OSGi issue with javax.xml.crypto API packages included in Santuario xmlsec.jar

["Colm O hEigeartaigh (JIRA)" <ji...@apache.org>]

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

Colm O hEigeartaigh closed SANTUARIO-358.
-----------------------------------------


> OSGi issue with javax.xml.crypto API packages included in Santuario xmlsec.jar
> ------------------------------------------------------------------------------
>
>                 Key: SANTUARIO-358
>                 URL: https://issues.apache.org/jira/browse/SANTUARIO-358
>             Project: Santuario
>          Issue Type: Improvement
>      Security Level: Public(Public issues, viewable by everyone) 
>          Components: Java
>    Affects Versions: Java 1.5.4
>            Reporter: Kai Rommel
>            Assignee: Colm O hEigeartaigh
>             Fix For: Java 2.0.0
>
>
> Using Santuario within OSGI (Equinox) I encountered some issues. The used OSGi system is exposing the javax.xml.crypto packages from the jdk with version 0.0.0. The jar xmlsec also exposes these packages with another version. As my application is running in a OSGi environment it should be possible to register different providers and to use these.  These providers are registered within  the java.security.Security class. Does my application load the santuario provider “ApacheXMLDSig” (form provider class org.apache.jcp.xml.dsig.internal.dom.XMLDSigRI) and my bundle/application loaded the java.xml.crypto packages with the jdk version, I will get an class cast exception.
> I would like to deploy santuario without following packages
>  javax.xml.crypto, 
>  javax.xml.crypto.dom, 
>  javax.xml.crypto.dsig, 
>  javax.xml.crypto.dsig.dom, 
>  javax.xml.crypto.dsig.keyinfo, 
>  javax.xml.crypto.dsig.spec, 
> I suppose this was also the reason for putting the xml parser APIs into a separate .jar.
> There are different solutions to this problem:
> 1. The santuario bundle could have an optional import of the named packages and expose them a second time. In addition the Apache WSS4J bundle must also be changed, as it needs the packages with the santuario version.
> Or
> 2. Package santuario implementation without the javax.xml.crypto packages. These packages could be provided in a separate jar/OSGi bundle (like it is done for the xml parser APIs in xml-apis-1.3.04.jar).
> Is there any reason why you used to use the version of santuario for the javax.xml.crypto packages? I think the version of the corresponding specification (Java XML Digital Signature ) is 1.0. 
> Best regards
> Kai



--
This message was sent by Atlassian JIRA
(v6.2#6252)