Jogl Build Headache

Ok I have come full circle and I am back to my initial error...

Thread=Thread[Thread-17,4,http://zenny-x11.home/play/-threadGroup]
 java.lang.ExceptionInInitializerError
  com.jogamp.newt.awt.NewtCanvasAWT.<clinit>(96)
   com.MyTestApp.core.Main.<init>(89)
    com.MyTestApp.core.Main.init(10)
     sun.reflect.NativeMethodAccessorImpl.invoke0(-2)
      sun.reflect.NativeMethodAccessorImpl.invoke(-1)
       sun.reflect.DelegatingMethodAccessorImpl.invoke(-1)
        java.lang.reflect.Method.invoke(-1)
         com.MyTestApp.load.Main$Com.init(304)
          com.MyTestApp.load.Main$Com.access$4500(138)
           com.MyTestApp.load.Main$Library$DefaultLibraryChecker.run(741)
            java.lang.Thread.run(-1)

Line 96 in com.jogamp.newt.awt.NewtCanvasAWT is...

    public static final boolean DEBUG = Debug.debug("Window");


How my app works is it downloads additional jars from my page server, including gluegen and jogl, and saves them to the user appData dir. The jars are then added to the applet classloader.

I am wondering that as this is the way I am using these jars that I need to call an init routine manually???

I see a initSingleton in jogamp.newt.Debug

Does anyone know of the correct method to instantiate gluegen and jogl??

many thanks
Penny

Excellent! Glad it finally works :)

Penny wrote

thank you gouessej - you have help me a lot over the last few years.

You're welcome. Personally, I sign everything with the same self-made certificate (not a trusted one) but I know I'll have to buy a certificate next year :( I'm glad for you.

I have a snag...

I create a ClassLoader and load my external jars as URLs.

I can find and load the classes in the jars fine but getResource() for image files etc is not working.

getResource() works fine using javaw but it doesn't work in a browser applet. All the jars are trusted with codebase and signed.

What do I need to do to be able to get the resource URLs of the image files in my dynamically loaded jars?

Many Thanks
Penny

Call getResource or getResourceAsStream on the right class to use the right classloader. It works in my case, my images aren't in the same JAR than Ardor3D and JogAmp JARs. Check that your URL is correct, I wasted some time because of a missing "/" when I started using Java Webstart, it was working only in command line.

Hi Gouessej,

I looked at the URLs and they are fine as my loader applet returned valid URLs on getResource().

What seems to be the trouble is that whilst my "loader" applet is signed and trusted and has full system access the classes which are dynamically loaded are not. Every time I try to access a file, system clipboard and class loaders, eg whats outside the sandbox, I get access control exceptions...

java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "getClassLoader")

Any thread entering the dynamically loaded classes losses its security clearance and despite passing valid URLs to these classes they cannot access the files despite being in trusted and signed jars.

Is there some way I can enable these dynamically loaded classes to the same status as the applet loader?

My next step would be to pass simple data structures from the loader to the dynamically loaded classes if I cannot give my dynamically loaded classes security clearance.

My little trick is an unsecured thread makes a call to the applet loader with the required resource name. The applet loader has an internal sleeping thread that is notified by the unsecured thread, the unsecured thread then subsequently waits. The internal secured thread then performs the getResource() with the provided name and loads the image or data to a buffer then passes this information to the waiting unsecured thread and notifies it before waiting. The unsecured thread then returns with the required data.

If I cannot enable my dynamically loaded classes security clearance this is what I will need to do all be it a little long winded and it would need to by synchronized to ensure only 1 fetch occurred at a time.

Please help.
Regards
Penny

Hiya,

I believe I have resolved my problem completely.

My loader applet downloads the additional jars and saves them to user.home

I have designed my own class loader that has the applet class loader as its parent so it has the loader applet trusted privileges.

The class loader goes through each downloaded jar and through each entry and verifies that it is signed and valid with the same certificate used to sign and trust the loader applet.

If the class certificate has been verified I then call defineClass using the same byte buffer that I loaded to verify the certificate and a code source object.

Some classes throw a LinkageError and I believe it is because these classes are already defined so I ignore and move on to the next class. Classes may already be defined during resolving of other classes. I hope that the classes that are automatically loaded during resolving have the trusted privileges.

If any class fails its certificate the loader halts with a message "Stop trying to hack my software you loser!" haha

Result: I invoked a method on a dynamically loaded class and it was able to access its own classloader as well as the current thread context class loader which I do believe should raise a access control exception if it did not have the trusted privileges.

I guess it will take me a few weeks to port my test project classloader into my project but fingers crossed!!! :)

Hi

Penny, just keep in mind that the security model of Java is quickly changing, I hope your impressive stuffs will go on working. You don't lack of humor :)

Just for your information, there are some simple ways of preventing your JARs from being re-purposed without dynamically downloading and loading them.