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 withname conflicts for their local libs that cannot be used together.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

Quote

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

Quote

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.)

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

Quote

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).

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!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org