santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 42820] New: - ClassLoader issue causing NoSuchAlgorithmException loading Provider Implementation
Date Thu, 05 Jul 2007 18:33:19 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42820>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42820

           Summary: ClassLoader issue causing NoSuchAlgorithmException
                    loading Provider Implementation
           Product: Security
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Signature
        AssignedTo: security-dev@xml.apache.org
        ReportedBy: jwashington@thezenith.com


A ClassLoader issue is causing NoSuchAlgorithmException to be thrown when
loading a Provider implementation from the getImpl() method in XMLDigSecurity
object. The bug manifests within a J2EE application container when two separate
applications (EAR files) register and reference providers using the local
ClassLoader provided by the container. The following scenario causes the failure
condition: Application A (within one EAR file) registers a security provider in
the java.security.Security object, which is loaded by the primordial class
loader. At some later point, application B (in another EAR file) instantiates
the security provider loaded by A. The getImpl method in XMLDigSecurity
determines the base class typeClass using the class member value (such as
javax.xml.crypto.TransformService.class) and thus implicitly loads this class
via the current class loader. A call to doGetImpl loads the implementation class
using the class loader of the provider registered in java.security.Security and
then does a super class check between the the base class and the loaded
implementation class. Since the type class is loaded from the class loader in B
and the implementation is loaded by class loader in A, the super class check
fails and a NoSuchAlgorithmException is thrown.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message