seanjmullan commented on PR #204: URL: https://github.com/apache/santuario-xml-security-java/pull/204#issuecomment-1714524482
Thanks. I think you may have misunderstood my latter comment though. What I was thinking if we could run all of the tests with this profile and be sure that BC was used as the default JCE provider for all of the tests, as this would give us a better assurance that all Santuario APIs worked across the board with different JCE providers. Typically this would be done by editing the `java.security` file and adding it as the first provider. For testing, however, modifying the JDK under test is usually not a viable option, so this could be done instead by specifying an alternate `java.security` file with the `java.security.properties` system property, ex: `java -Djava.security.properties=my.java.security ...` where `my.java.security` is a file with an entry with the first provider as BC followed by the existing JDK providers, all renumbered, something like: ``` security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider security.provider.2=SUN security.provider.3=SunRsaSign security.provider.4=SunEC security.provider.5=SunJSSE security.provider.6=SunJCE security.provider.7=SunJGSS security.provider.8=SunSASL security.provider.9=XMLDSig security.provider.10=SunPCSC security.provider.11=JdkLDAP security.provider.12=JdkSASL security.provider.13=Apple security.provider.14=SunPKCS11 ``` This might be a bit hard to pull off, but would be a very valuable feature as it would provide comprehensive interoperability testing of at least 2 different JCE providers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
