JNLP Solution Posted

[Jeff]

Okay,

I just updated CVS with a version that has a solution (I hope) for the JNLP problem.

Setting the property "net.java.games.util.plugins.nolocalnative" to any value on your java command line
(eg "-Dnet.java.games.util.plugins.nolocalnative=true")
will force it to skip the code that makes it look in the Jar's directory for the native lib and instead fall back to whatever the default behavior is for that environment.

Recognize that in this mode there may be plug-ins with
name conflicts for their local libs that cannot be used together.

[gregorypierce]

What is the behavior going to be for jogl and joal? I'm still confused as to why jogl works just peachy yet jinput has issues.

[gregorypierce]

Nevermind, I understand what the issue is now. What is odd is that the JUtil plugin engine doesn't use the context classpath classloader when trying to load classes.

Jeff the fix that you put in is using the context classpath classloader or does it do something else?

Games published by our own members! Check 'em out!

[TheBohemian]

I am suprised too. I thought I had found the solution already?

Did I forget to make clear that using the context classloader solves all the problems?

I thought using a property like net.java.games.util.plugins.nolocalnative broke the intention of the plugin mechnism because the native library (the plugin) has to be mentioned in the JNLP file.

Taking the context classloader-approach doesn't need this. Still you have pre-install the plugin but that can now be done with an installer.

[Jeff]

Nevermind, I understand what the issue is now. What is odd is that the JUtil plugin engine doesn't use the context classpath classloader when trying to load classes.

Jeff the fix that you put in is using the context classpath classloader or does it do something else?

All the fix does is disable the override of getLibrary on the plug-in class loader.  That over-ride is what makes it find the DLL in the same directory as the plug-in.

So with the porperty defined its now using the default class loader behavior for finding the native library, which I assume is what JOGL and JOAL do since they likely don't define custom class loaders at all.

[Jeff]

I am suprised too. I thought I had found the solution already?

Did I forget to make clear that using the context classloader solves all the problems?

When you say "context classloader" what are you referring to?  The bootloader?  The classpath class loader?  I'm afraid I'm not following the term.

I thought using a property like net.java.games.util.plugins.nolocalnative broke the intention of the plugin mechnism because the native library (the plugin) has to be mentioned in the JNLP file.

Yep it does.  I just accepted that as a limitation of JNLP distributed code, that they are going to have to have apriori knowledge of what plugins they are using.  Since you need this knowledge ANYWAY to prepare the download jars, it didn't seem to me like it was making things any more limited then they already are

Taking the context classloader-approach doesn't need this. Still you have pre-install the plugin but that can now be done with an installer.

Right, and thats a great solution if the player wants to install it into his/her JRE, but I wanted to make both options still available to JNLP programs.  (Install into JRE or make a part of your app.)

[TheBohemian]

When you say "context classloader" what are you referring to?  The bootloader?  The classpath class loader?  I'm afraid I'm not following the term.

I thought of this one: Thread.currentThread().getContextClassLoader(). When accessing resources in a JNLP application one has to use this instead of the SystemClassLoader.

Right, and thats a great solution if the player wants to install it into his/her JRE, but I wanted to make both options still available to JNLP programs.  (Install into JRE or make a part of your app.)

To achieve this (both options) it is neccessary to change the  code in Plugins.java and PluginLoader.java to use the context classloader as well. Using the property to get things working only, results in being unable to load any installed plugin (security or classnotfound exception like I mentioned in the other thread).

[Jeff]

Ah.  I see.  What you are referring to is the loader used by the current class, in other words JWS's own custom class laoder.

This makes sense.  I'll change the parenting of the plugin-loader so iuts created as a child of the currentContextLoader.

Shouldn't be hard  I'l let you know when its done and if you can test it that would be great.

[Jeff]

Okie.

I've updated the Jutils PluginLoader code so that it creates itself using the current thread context loader.

Give it a shot and see if it works please?

[TheBohemian]

I wonder if you had read my long post in the other thread

*quoting myself*

The only real problem is that PluginLoader is created without a parent that is able to find the class ControllerEnvironment. I think it would be pretty easy to fix the problems we have at the moment:
PluginLoader should be given the context class loader as parent!

*modifying jutils*
*recompiling*
*signing*

I can happily admit: This works! It fixes all problems!

Nice to have an official solution. Now I can change my jinputtester

Games published by our own members! Check 'em out!

[Jeff]

YepI had read it but I didn't completely follow it.  I had to work through
the issues myself to understand why it was necessary.

Gald it works now!  Thanks guys for bearing with me and pushing on this

JK

[TheBohemian]

Hm. I think that it is not working correctly. More details here:
http://www.JavaGaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jinput;action=display;num=1064272481;start=15#15

[Jeff]

AFAICS the referenced thread is old.

Are we now working correctly?  if not, what are the remaining issues?

JK