Jogl initialisation

Hiya,

My project is an applet which runs within a browser.

If I include gluegen and jogl in the html object the classes are loaded unsigned and are unable to access resources. An access control exception occurs. I don't know why these classes are loaded without permissions because everything is signed and trusted.

Alternatively, and ideally, I have attempted my loader applet to download the gluegen and jogl jars dynamically, save them to the repository and then define each class with the appropriate ProtectionDomain.

The problem here is I get java.lang.ExceptionInInitializerError.

Does anyone know how to "initialise" or "instantiate" the gluegen and jogl classes when they are dynamically loaded?

or does anyone know how to make gluegen and jogl privileged if they are loaded in the html object.

thanks
Penny

Hi

Do you sign JogAmp JARs by yourself?

yes, every jar is signed with the same certificate, my self-cert. If they are not all signed with the same cert a security error occurs.

My app loads as trusted but jogl doesn't for some reason. I receive an access control exception when one of the jogl classes attempts to access its classloader.

As that doesn't seem to be working I am currently attempting to load the natives manually before jogl is initialised.

gluegen-rt.dll and nativewindow_awt.dll load ok

but I am getting the following error...

 java.lang.UnsatisfiedLinkError: C:\Users\Penny\AppData\MyApp\natives\windows-amd64\nativewindow_win32.dll: %1 is not a valid Win32 application

I have no idea why this is doing this.

Regards
Penny

Why is it trying to load the dll directly from the filesystem and not from a temp folder after being extracted from the -natives
jar?  Have you modified the native loading code somehow?  The error messge suggests you were loading the 64 bit dll into a 32-bit VM.

Harvey

That's just the name of the file but it is in the amd64 natives so.

I believe it is because the file needs to be loaded using System.loadLibrary() instead of System.load()

I believe when jogl initialises in the standard way the file is unpacked to a temp location which is probably the applets temp sandbox. I will do some more digging to see if I can mimic this...

Thanks
Penny

Penny wrote

I believe it is because the file needs to be loaded using System.loadLibrary() instead of System.load()

I believe when jogl initialises in the standard way the file is unpacked to a temp location which is probably the applets temp sandbox. I will do some more digging to see if I can mimic this...

Why not trying to use the build-in automatic extraction and loading of native libraries as is? Your problem would become our problem instead of having to maintain yet another "solution" by yourself.

I have figured it out.

In a nutshell I needed to override the loadClass functions in my class loader.

The reason is that defineClass subsequently calls loadClass to define dependents and the parent class loader defines classes without any permissions. My class loader was then generating "Already Defined" when it tried to define the dependent classes with permissions.

By overriding the loadClass functions I ensure every class is defined with permissions.

Thank you

some natives will load using System.load() so having a path to the unpacked natives is ok.
but some natives will only load using System.loadLibrary() which will not allow a path.
I am thinking of unpacking the natives to the absolute path of File(".");
initialising jogl.
and then deleting the natives.

I haven't figured out where jogl/gluegen puts the natives that require System.loadLibrary() yet...

Actually, maybe this is not the problem. When there are dependencies between native libraries, you have to handle them by yourself even though they are "reachable" by using System.loadLibrary which looks in the Java library path and in some environment variables (system dependent).

I agree.
I don't really wish to start changing environment variables or the java library path.

I think jogl/gluegen saves the natives to System.getProperty("java.library.path");

I will have a play :)