I am developing an applet to digitally sign files from a web application, using JCAPI. Initial tests work fine, but i have found that there is a problem with Internet Explorer, when the page that includes the applet, is reloaded with Ctrl+F5 (that is, bypassing browser cache). If page is reloaded that way, an Exception is thrown, saying that dll is already loaded by another class loader.

It happens just with IE (works fine on Firefox and Opera), and just with Ctrl-F5 reload (just pressing F5, works fine)

It seems than Internet Explorer unloads all Java classes, so when loaded again, static initializers are re-executed. I guess that JCAPI uses a boolean static atribute to check if dll has been loaded, and that static mark is setted to its original value.

Anyway, I have implemented my own checking, with a boolean static atribute, and a static method that executes "Security.addProvider(new JCAPIProvider())". Code is like this:

    private static boolean ini = false;



    public static void init() {

        if (! ini) {

            java.security.Security.addProvider(new com.pheox.jcapi.JCAPIProvider());

            ini= true;

        }

    }

Adding logging to this code, shows that when applet is reloaded in IE, when reeloading page with Ctrl+F5, private static boolean ini atribute is set to false again. But dll is already loaded by the JRE, so an Exception is thrown.

I have used a system property to avoid this (using java.lang.System.getProperty and java.lang.System.setProperty), checking and setting it when adding JCAPI provider. In this case, code is not executed when applet is reloaded with Crtl+F5, but then an exception is thrown when I try to use JCAPI after reload, saying than JCAPI provider has not been added.

I know that it seems to be an IE bug, not JCAPI bug, but ¿Is there any kind of workaround? If not ¿are there plans to make it possible (maybe allowing JCAPI to ignore dll load exceptions, if developer want to)?

Hi,

That's an old problem. It's a type safety feature of the Java Virtual Machine - that is loading of the same JNI native library by separate class loaders is not allowed (for more info, see http://java.sun.com/docs/books/jni/html/design.html#862.

There are a couple of solutions available to circumvent this; the simplest (and ugliest) solution is to add the JCAPI provider (and thus dynamically load the JCAPI DLL) each time the applet is loaded. To ensure name space separation based on class loaders and still avoid exceptions will require you to load the same DLL, but with a DIFFERENT name. This means that the DLL must be renamed before adding the JCAPI provider. An annoying side effect here is that there will be multiple instances of the same DLL loaded into the JVM which in turn will increase the process space.
Here's an example of how this can be implemented:

void addJCAPIProvider()

    throws Exception

{

    //Use a temporary JCAPI DLL in a temporary directory.

    File dir = new File(System.getProperty("java.io.tmpdir") + "/jcapitmp");

    JCAPIDLL.getInstance().setDirectory(dir);

    String dllName = "JCAPIweb_" + Long.toString(System.currentTimeMillis()) + ".dll";

    JCAPIDLL.getInstance().setFilename(dllName);

    if(!dir.exists())

        dir.mkdir();

    else

        {

            //Perform cleanup.

            //Delete all JCAPI DLLs that are not already loaded into the JVM(s).

            File[] files = dir.listFiles();

            if(files.length > 0)

                {

                    for(int i = files.length - 1; i >= 0; i--)

                        files[i].delete();

                }

        }



    Security.addProvider(new JCAPIProvider());            

}

A more sophisticated solution (using JCAPI in an applet which resides in a hidden frame and then use applet-to-applet communication with the applet that is reloaded) of the same problem can be found here:
http://www.javaworld.com/javaworld/javatips/jw-javatip101.html

Regards,
Tommy

Thanks Tommy,

I will try first option, combined with a static checker to avoid too many dll loads (just add JCAPI provider again when a Crtl+F5 reload is done).

Second option will requiere a separate minimized window, as a frame in the same window will not do it (page reload will reload both main and applet frame, and it could even load home page in main frame, loosing previous navigation). I am not sure clients (or my project manager) would like that. Well, maybe I'll try that if I get too desperate