[jira] Created: (SUREFIRE-583) When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are

["Justin Searls (JIRA)" <ji...@codehaus.org>]

When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are
-------------------------------------------------------------------------------------------------------------

                 Key: SUREFIRE-583
                 URL: http://jira.codehaus.org/browse/SUREFIRE-583
             Project: Maven Surefire
          Issue Type: Bug
          Components: process forking
    Affects Versions: 2.4.2
         Environment: Windows, JAVA_HOME is Sun JDK 1.6.0u16, forked JVM is IBM JDK for WAS 6.1
            Reporter: Justin Searls


Premise: 
My test needs to run on the IBM JDK to work, but for other reasons I need to actually build on the Sun JVM. My application's tests are relying on 
libraries that use a message digest ("SHA", not "SHA1") that I can only find support for in the BouncyCastle JCE provider. 

Setup:
1. So I've identified in my plugin configuration something like <jvm>/path/to/ibm/jdk/jre/bin/javaw.exe</jvm>
2. Added BouncyCastle JCE provider jar to /path/to/ibm/jdk/jre/lib/ext
3. Setup BouncyCastle as the sole JCE provider in /path/to/ibm/jdk/jre/lib/security/java.security

Expected Result: Designated IBM JVM would look for its java.security file and load its jre/lib/ext JARs when executing tests
Actual Result: No such effect. After going through the same setup on my Sun JDK (which I'm running Maven with), that did have the effect of actually providing that provider and getting past the error I was experiencing.

It seems to me that if you fork to a different JVM, that JVM's security policy should be used. Given the complexity of this API, however, I wouldn't be surprised to hear that there's a major technical hurdle in implementing this, however.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] (SUREFIRE-583) When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are

["Kristian Rosenvold (JIRA)" <ji...@codehaus.org>]

     [ https://jira.codehaus.org/browse/SUREFIRE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kristian Rosenvold updated SUREFIRE-583:
----------------------------------------

    Fix Version/s: Backlog
    
> When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: SUREFIRE-583
>                 URL: https://jira.codehaus.org/browse/SUREFIRE-583
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: process forking
>    Affects Versions: 2.4.2
>         Environment: Windows, JAVA_HOME is Sun JDK 1.6.0u16, forked JVM is IBM JDK for WAS 6.1
>            Reporter: Justin Searls
>             Fix For: Backlog
>
>
> Premise: 
> My test needs to run on the IBM JDK to work, but for other reasons I need to actually build on the Sun JVM. My application's tests are relying on 
> libraries that use a message digest ("SHA", not "SHA1") that I can only find support for in the BouncyCastle JCE provider. 
> Setup:
> 1. So I've identified in my plugin configuration something like <jvm>/path/to/ibm/jdk/jre/bin/javaw.exe</jvm>
> 2. Added BouncyCastle JCE provider jar to /path/to/ibm/jdk/jre/lib/ext
> 3. Setup BouncyCastle as the sole JCE provider in /path/to/ibm/jdk/jre/lib/security/java.security
> Expected Result: Designated IBM JVM would look for its java.security file and load its jre/lib/ext JARs when executing tests
> Actual Result: No such effect. After going through the same setup on my Sun JDK (which I'm running Maven with), that did have the effect of actually providing that provider and getting past the error I was experiencing.
> It seems to me that if you fork to a different JVM, that JVM's security policy should be used. Given the complexity of this API, however, I wouldn't be surprised to hear that there's a major technical hurdle in implementing this, however.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira