JNLP: Зареждане на неподписан код в рамките на подписания код

Имаме затруднения да преодолеем грешката със смесен код за Java webstart. В обобщение, имаме нашия основен JNLP файл, подписали сме целия си код, който той зарежда директно. Добавихме опцията за всички разрешения към основния JNLP. Основният клас, който зарежда, също идва от подписан буркан.

Когато основният клас стартира малко по-надолу по пътя, той задейства някои неща, които трябва да заредят някои неподписани ресурси, които са изтеглени от JNLP B. Никой от ресурсите на JNLP B не е подписан и не се нуждаят от специални разрешения.

Целият подписан код е настроен въз основа на документацията за смесен код от Oracle и jar файловете са зададени с манифести на „Trusted-Library: true“ преди подписване.

Когато неподписаният код се опита да бъде зареден от подписания код, получаваме грешка, че класът не е намерен, както следва:

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

    Caused by: java.lang.NoClassDefFoundError: org/some/external/package/that/is/not/signed
at org.our.signed.package.main(Main.java:87)
... 9 more

    Caused by: java.lang.ClassNotFoundException: org.some.external.package.that.is.not.signed
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 10 more

Ето сценария в JNLP:

JNLP A: (обобщено)

<jnlp spec="1.5+" codebase="...." href="/bg......">
  <information>
   ...etc
  </information>
   <security>
     <all-permissions/>
   </security>
   <resources>
      <j2se version="1.6+" initial-heap-size="80m" max-heap-size="256m" href="http://java.sun.com/products/autodl/j2se"/>
      <jar href="/bgsignedJar_1.jar" download="eager" main="true"/>
      <jar href="/bgsignedJar_2.jar" download="eager" main="false"/>
      <extension name="unsigned_ext" href="/bgunsigned.jnlp"/>
  </resources>
  <application-desc main-class="(FROM SIGNED CLASS in signedJar_1.jar)"/>
</jnlp>

JNLP B (зареждащото устройство unsigned.jnlp)

<jnlp spec="1.5+" codebase="....." href="/bg......">
  <information>
   ...etc
  </information>
  <resources>
    <jar href="/bgunsigned.jar"/>
  </resources>
  <component-desc/>
</jnlp>

Отбелязахме, че изключенията за защита работят правилно, защото ако преместим неподписания буркан в JNLP, който има всички разрешения и подписани буркани, получаваме очакваните изключения за сигурност, с които Java няма да ни позволи да смесваме подписания код Trusted-Library: истински и неподписан код без манифестни атрибути.

Идеи? Има ли причина зареждането на класове да не може да намери java файловете от неподписания код? Има ли нещо специално, което пропускаме, за да позволим на подписания код да изпълнява неподписан код? Виждал съм само случаите, в които хората имат проблеми с получаването на неподписан код, за да изпълняват подписан код, което мога да разбера.