FULL PRODUCT VERSION :
Latest 1.6.0_21 build. Problem occurs in 1.6.0_19 and greater.

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows Version 6.1.7600

EXTRA RELEVANT SYSTEM CONFIGURATION :
Firewall disabled, direct network connection, running as administrator

A DESCRIPTION OF THE PROBLEM :
Having troubles with security in the latest JRE when trying to connect to a J2EE Application server over rmi/iiop, but ONLY when running from cache. A "freshly" downloaded client (jars) connects and runs perfectly. I am trying to figure out what the diff is between the cached and newly downloaded app's sandbox, and why I can read/write without issue but get generic RMI/CORBA errors when talking to the appserver when the client is cached.

1. All jar files referenced as resources in the JNLP are signed by the same certificate, and ONLY that certificate.
2. All Permissions is requested in the security tag of the JNLP for the application sandbox.
3. If I disable the "mixed-code" security checking in the Java Control Panel, the client launches every time, either on first download or cached version:
- Again, all jars are signed by the same certificate and I do not get the "mixed-code" warning at either type of launch when security is on
4. If I include a property in the JNLP and package up a grant all permissions policy file:
-
<property name="java.security.policy" value="$$context/cu/properties/java.policy"/>

- I now have the same behavior as before, but I can do an "r" to "reload policy configuration" in the Java Console (turned on from control panel for troubleshooting) and am able to run the application through the cache

Why is there a difference in the sandbox permissions for a trusted app when it is newly downloaded or running from cache? Why am I not getting "All Permissions" when requesting it in the JNLP, especially since the application is trusted and all resources are signed by the same certificate?


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
J2EE Application client downloaded and run via Java Web Start. Client initiates an rmi/iiop connection wrapped by the T3 protocol for WebLogic. If the client is fully downloaded and run, the connection works without issue. If the client is run from cache, on-line, a generic RMI CORBA exception is thrown.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expect the cached version of the application to work exactly the same as a newly downloaded version.
ACTUAL -
Cached version fails

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="$$context" spec="1.0+" href="$$context/Ajility.jnlp">

<!--Provide application information-->
  <information>

    <title>Ajility Client</title>
    <vendor>Columbia Ultimate</vendor>
    <homepage href="index.html"/>
    <description>Ajility Client Installation with Java Web Start</description>
    <description kind="short">Ajility Client</description>
    <icon href="$$context/cu/images/Ajility_logo.jpg"/>

  </information>

<!--Set security for sandbox-->
  <security>
    <all-permissions/>
  </security>
  
  <update check="always"/>

  <resources>
   <!--Set properties that will be used as JVM -D arguments-->
<j2se version="1.6"/>
<property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory"/>
    <property name="java.naming.provider.url" value="t3://eng-build1:7001"/>
<property name="java.security.auth.login.config" value="$$context/cu/properties/jaas_client.conf"/>
<property name="java.security.policy" value="$$context/cu/properties/java.policy"/>
<property name="appserver.connector.class" value="com.cu.ajility.appserver.weblogic.WebLogicConnector"/>

  <!--Resource jar with MAIN-->
    <jar href="cu/lib/AjilityGUI.jar"/>
<jar href="cu/lib/AjilityCommon.jar"/>
<jar href="cu/lib/AjilityConnectors.jar"/>
    <jar href="cu/lib/core.commands.jar"/>
    <jar href="cu/lib/core.runtime.jar"/>
    <jar href="cu/lib/equinox.common.jar"/>
    <jar href="cu/lib/equinox.registry.jar"/>
<jar href="cu/lib/jface.jar"/>
    <jar href="cu/lib/jface.text.jar"/>
    <jar href="cu/lib/osgi.jar"/>
    <jar href="cu/lib/ui.forms.jar"/>
    <jar href="cu/lib/alm.jar"/>
<jar href="cu/lib/log4j.jar"/>
<jar href="cu/lib/joda-time-1.6.jar"/>
    <jar href="cu/lib/wlclient.jar"/>
    <jar href="cu/lib/webserviceclient+ssl.jar"/>
<jar href="cu/lib/com.bea.core.descriptor.wl_1.1.0.0.jar"/>
<jar href="cu/lib/wlfullclient.jar"/>
<jar href="cu/lib/wls-api.jar"/>
  </resources>
  
   <resources os="Windows" arch="amd64">
<jar href="cu/lib/64/swt.jar"/>
   </resources>
   
   <resources os="Windows" arch="x86">
<jar href="cu/lib/32/swt.jar"/>
   </resources>

  <application-desc/>

</jnlp>

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Disable Mixed Code Security in the Java Control Panel.

SUPPORT :
YES

Release Regression From : 6u18
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.