Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (116)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Problem with JNLP and JInput  (Read 4876 times)
0 Members and 1 Guest are viewing this topic.
Offline TheBohemian

Junior Member




Java will rule them all!


« Posted 2003-09-22 21:14:40 »

I want to apply webstart functionality for my JInput based application (the JInputTester you may know) and cannot get around the problem with the native plugins.

When not using JInput as an extension the file structure has to be this way (I think that because I have tested it. Any documentation on that?)

appDir:
application.jar
jinput.jar
jutils.jar
controller [containing platform dependant files]

This assumes to have jinput.jar and jutils.jar in the classpath (specified by the jar's manifest and/or the JNLP file).

When webstart downloads everything and my application launches there're no problems but it cannot find any devices because of missing plugin libraries.

Is there any solution to this?

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #1 - Posted 2003-09-22 21:29:16 »

Have you tried bundling the controller folder into a JAR and including that in the Web Start resources?

Check the jutils source to see how plugins are loaded and it might help.

Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #2 - Posted 2003-09-22 22:42:27 »

Bundling the folder and including it as a nativelibrary in the resources sections doesn't work because JNLP specification says the files have to be in the root of the jar. I checked webstart's cache folders and nothing was extracted.

I had the idea to set the property jinput.controllerPluginPath to "." and put the plugin files at the root of the jar. This doesn't help as I found out that the property user.dir which is used by DefaultControllerEnvironment is set to everything but not the real path webstart is using for its file caching.

Maybe I have to admit that webstart generates a subfolder for jar files which should contain native libs. This makes things even worse because other JNLP clients may not do it this way. So special workarounds for webstart are not a good idea ...

Well, now I have better insight on how JInput scans for plugins but I can say that I am not very happy with that. Why 'user.dir' ?

Problems may also arise when no webstart is in use:
One might start a downloaded application (which contains the application jar, jinput.jar/jutils.jar and a controller subfolder) from a different location than the application folder and will not find any input devices because jinput did not find its plugins.

Isn't there any other method to load the plugins that uses the existing classpath?

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-09-23 00:05:17 »

I think the solution is to use WebStart to launch an extension installer that installs the jinput stuff directly into the JRE extensions folder.  I think the "controller" folder can go in the JRE lib folder right?

But, I agree it would also be nice if it could be worked around so the JRE folders don't need to be touched and it can still work with Web Start.

Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #4 - Posted 2003-09-23 00:06:03 »

This looks very bad: I have tried some tricks and hacks to get it working with webstart (mainly trying to get the absolute path of the folder where webstart saves the native libs) but it doesn't work because any jar that is inside the containing the native library is not added to the classpath ...

Even when the plugin is already installed on my machine webstart applications are not allowed to do the loadLibrary call. This exception proves that:

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.dxinput)
     at java.security.AccessControlContext.checkPermission(Unknown Source)

     at java.security.AccessController.checkPermission(Unknown Source)

...

Edited after having seen swpalmers recent post:
An extension installer may have the problem I stated above, too. Or am I wrong?

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #5 - Posted 2003-09-23 00:36:54 »

The installer itself must be signed so it can write to the JRE folders. But after that the Web Start apps that need jinput should just work, and they should never need to download and install Web Start again unless there is an update. I think the jinput classes will be trusted once they are in the JRE folder So loading the plugin DLLs shouldn't be a problem.

Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #6 - Posted 2003-09-23 01:14:30 »

The exception in my last post was done when the plugin was already installed in ${jdk.home}/lib/controller. Maybe this is a bug in webstart because I cannot find any information in the JNLP specs that is saying that it is not allowed to load native libraries when 'all-permissions' are granted.

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #7 - Posted 2003-09-23 01:42:34 »

A WebStart app definitely IS allowed to load native DLLs when all-permissions are granted.  Of course for that to work that JAR must be signed too.

Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #8 - Posted 2003-09-23 18:26:01 »

You may try this:
http://page.inf.fu-berlin.de/~rschuste/java/jinputtesterFU.jnlp

(the link has to be put into the address line of webstart. don't know why it doesn't start the application properly. the admins say the server has registered the MIME type ...)


cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #9 - Posted 2003-09-23 19:30:39 »

I tried it and there was no error in the console window but it obviously didn't work because it shows no devices.

P.S. Make the application exit when the window is closed. It is really annoying to have to go killing processes as it is now.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #10 - Posted 2003-09-23 20:47:16 »

Oh, I assumed to test it with installed plugins. Please install the plugins for the JRE that runs webstarted applications and have a look at the strange exception JInputTester then throws.

Regarding the exit-Feature: When everything works well JInputTester ends all threads so the VM shuts itself down. I wonder what the official recommendation is explicitly or implicitly shutdown the VM?

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #11 - Posted 2003-09-24 14:46:48 »

Ok, I ran it from the command line in my home folder where the "controller" folder is.  It seems that the plugin JAR does not have permission to run native code.

Java Web Start 1.2 Console, started Wed Sep 24 11:53:35 EDT 2003
Java 2 Runtime Environment: Version 1.4.1_01 by Apple Computer, Inc.
Logging to file: /Users/scottpalmer/webstart.log
Scanning jar: HIDWrapper.jar
Examining file : META-INF/
Examining file : META-INF/MANIFEST.MF
Examining file : net/
Examining file : net/java/
Examining file : net/java/games/
Examining file : net/java/games/input/
Examining file : net/java/games/input/InputController.class
Examining file : net/java/games/input/InputControllerElement.class
Examining file : net/java/games/input/OSXEnvironmentPlugin.class
Found candidate class: net/java/games/input/OSXEnvironmentPlugin.class
Adding class to plugins:net.java.games.input.OSXEnvironmentPlugin
Examining file : net/java/games/input/OSXGamepad.class
Examining file : net/java/games/input/OSXJoystick.class
Examining file : net/java/games/input/OSXKeyboard.class
Examining file : net/java/games/input/OSXMouse$BallAxis.class
Examining file : net/java/games/input/OSXMouse$BallImpl.class
Examining file : net/java/games/input/OSXMouse$ButtonImpl.class
Examining file : net/java/games/input/OSXMouse$ButtonsImpl.class
Examining file : net/java/games/input/OSXMouse.class

Then:

java.lang.ExceptionInInitializerError
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
     at java.lang.Class.newInstance0(Class.java:306)
     at java.lang.Class.newInstance(Class.java:259)
     at net.java.games.input.DefaultControllerEnvironment.scanControllersAt(DefaultControllerEnvironment.java:183)
     at net.java.games.input.DefaultControllerEnvironment.scanControllers(DefaultControllerEnvironment.java:164)
     at net.java.games.input.DefaultControllerEnvironment.access$000(DefaultControllerEnvironment.java:57)
     at net.java.games.input.DefaultControllerEnvironment$1.run(DefaultControllerEnvironment.java:108)
     at java.security.AccessController.doPrivileged(Native Method)
     at net.java.games.input.DefaultControllerEnvironment.getControllers(DefaultControllerEnvironment.java:106)
     at robs.jinput.JInputTester.<init>(JInputTester.java:24)
     at robs.jinput.JInputTester.main(JInputTester.java:51)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:324)
     at com.sun.javaws.Launcher.executeApplication(Launcher.java:785)
     at com.sun.javaws.Launcher.executeMainClass(Launcher.java:747)
     at com.sun.javaws.Launcher.continueLaunch(Launcher.java:632)
     at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:359)
     at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:177)
     at com.sun.javaws.Launcher.run(Launcher.java:145)
     at java.lang.Thread.run(Thread.java:554)
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.jinput)
     at java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
     at java.security.AccessController.checkPermission(AccessController.java:401)
     at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
     at java.lang.SecurityManager.checkLink(SecurityManager.java:834)
     at java.lang.Runtime.loadLibrary0(Runtime.java:782)
     at java.lang.System.loadLibrary(System.java:832)
     at net.java.games.input.OSXEnvironmentPlugin.<clinit>(OSXEnvironmentPlugin.java:298)
     ... 25 more

What I'm not sure is if this is a bug in Web Start, or a feature that we aren't using properly...  e.g.  The classloader that Web Start uses to access the apps Jars probably has permission to load and run native code, and if the plugin is in the JRE folders it might get permission to load native code, but as it is the plugin Jar is in a "unknown" location in terms of what Web Start grant permissions to... well that's my theory so far...

Where are the jinput installation instructions?  I've got to take a closer look and try putting the plugins in other places.

Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #12 - Posted 2003-09-24 18:20:29 »

The installation instructions are in the APIDOC for ControllerEnvironment. The name 'controller' for the plugin library can be overriden by setting the property jinput.controllerPluginPath. The last one isn't documented anywhere. I found it in the sources of DefaultControllerEnvironment.

--- EDIT:

I have found an easy way to come around the problems but it cannot considered to be a solution because I modified the DefaultControllerEnvironment.
It looks for the value of the property 'jinput.plugin.class' and instantiates one if set. I implemented this as an alternative: When the property is not set the usual behaviour comes into play.

I really don't like modifying the library to my needs but currently this is the only way to get things working with webstart. Finally there would be a problem when someone has jinput.jar installed as an extension ...

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline Jeff

JGO Coder




Got any cats?


« Reply #13 - Posted 2003-09-24 22:50:42 »

Okay,

I'm still trying to fully understand the issue here.

Hardwiring the plugin class, even in a property, is definitely NOT the right answer as it violates the spirit and design of the plug-ins.  (That being that the user code should not need to be aware of what the underlying plugins are.)

I can easily see a permissions issue is as JWS should NOT allow arbitrary jars to run arbitrary downloaded native code-- this would be a bad security hole the size of a medium sized cement truck.

The solution to the perimissions issue is either:
(A) Sign your code so users have some confidence in granting you the access you request
(B) As others have said, use a signed installer to install JInput into the JRE itself where it can run with bootclasspath permissions.

I'm kind of curious.  Don't you have this same issue with JOGL as well?  If not, why not?



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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #14 - Posted 2003-09-25 00:05:08 »

I have no problems with JOGL because it conforms cleanly to what can be done with webstart. I sign all the jars I want the JNLP client to process and thats it. Or simply said: JOGL doesn't use the plugin mechanism.

For JInput the problems are: Access to the plugin is not possible because the two possible configurations for this do not work:
(I take the win32 plugin as an example)
1) Config: dxinput.jar dxinput.dll bundled in jinput-plugin-win32.jar (signed as well) and specified in the JNLP as nativelib.
Problem: How to tell DefaultControllerEnvironment to search in a directory called:
"E:\Dokumente und Einstellungen\RoB1\Anwendungsdaten\Sun\Java\Deployment\javaws\c
ache\http\Dpage.inf.fu-berlin.de\P80\DM~rschuste\DMjava\RNjinput-plugin-win32.jar" - this is specific to my system and to the JNLP client implementation. Theres no way to set "user.dir" at runtime to this.

2.) dxinput.jar and dxinput.dll pre-installed (by hand) in jre/lib/controller - the only directory that can be found by DefaultControllerEnvironment safely (optionally signed).
Doing things this way causes the exception swpalmer and me have seen.

I *really* did not want to modifiy the DefaultControllerEnvironment but after endless hours of trying & testing the hack was my last hope.

The only thing I say: Please test the application and have a look yourself.
If you want to see the code before starting webstart it is available here:
http://page.inf.fu-berlin.de/~rschuste/java/jinputtester.jar

(There is an obsolete class inside that was targeted to find out the path)

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #15 - Posted 2003-09-25 00:43:32 »

Quote
I'm still trying to fully understand the issue here.


The Plugin support of JUtils doesn't work with Web Start for some reason.  Even if the plugin & native code is already downloaded and installed, an app that is started with Web Start can't load them if they try to load native code.

I've filed an issue with JUtils.

Quote
I can easily see a permissions issue is as JWS should NOT allow arbitrary jars to run arbitrary downloaded native code-- this would be a bad security hole the size of a medium sized cement truck.

That's not it.  Even with a signed jar, or having the plugins already installed in the JRE lib and ext folder the native code will not load.

Quote
The solution to the perimissions issue is either:
(A) Sign your code so users have some confidence in granting you the access you request
(B) As others have said, use a signed installer to install JInput into the JRE itself where it can run with bootclasspath permissions.

I'm kind of curious.  Don't you have this same issue with JOGL as well?  If not, why not?

A & B don't work.

As TheBohemian said above JOGL doesn't use the plugin stuff from JUtils.

Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2003-09-25 19:53:58 »

Hm.  The Jutil plugin stuff itself has no native code.

Can you email me the precise error?  or better yet point me at a small test case?  I'l ltry to promote this to the top of my list.

Thanks

JK

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #17 - Posted 2003-09-25 20:05:15 »

Quote
Well, now I have better insight on how JInput scans for plugins but I can say that I am not very happy with that. Why 'user.dir' ?


Because we wanted to have a way to load them relative to the game execution directory and that seemed the logical way.

I'd be happy to change this, lets get a consensus on what we want instead.

One solution would be to take the "user.dir" out of the code and instead define an escape sequence that means "working dir" or whatever is equivalent.

This seems a bit kludgy to me though.  is there a cleaner way to do this that will make JWS happy?

JK

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #18 - Posted 2003-09-25 23:09:57 »

When I made this complain I thought that using the plugin would be possible if only WS has a way to find them. Then came the exception ...

JUtil uses really no native code but for JInput the initialization of the plugin classes causes the call to System.loadLibrary(). And that is the exact location of the exception.

Win32:
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.dxinput)

MacOS:
Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission loadLibrary.jinput)

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #19 - Posted 2003-09-26 11:48:08 »

Hi
 Have you tried setting the property controllerPath (i think thats it, i'm not at home so I can't check) to the directory you wish to load jinput from?

Cheers

Endolf

Offline Jeff

JGO Coder




Got any cats?


« Reply #20 - Posted 2003-09-28 04:37:38 »

I am totally conused.

Are you saying the problem is that JWS prevents the scan for plug-in fiels from finding plugins?  Or that JWS permissions are preventing the native part of the plugin from being loaded?  (The excpetion you quoted sounds lke the latter-- that a plug-in IS in fact being found but that JWS is not allowing the link of the native JNI library portion.)

The latter should be no different for JInput then for JOGL.  If there is a diference, we need to get clear on what it is and why JWS doesnt like it.


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #21 - Posted 2003-09-28 18:51:35 »

Yes its the latter one. The exception is generated when the plugin class is loaded into the jvm and the static initializer attempts to load the native library. I am a newbie in Java's security management but I can cleanly see a difference between the loading mechnisms of JInput and JOGL:

A program is started via webstart. The JNLP file specifies jogl.jar as jar-ressource and its native library in the native section. With this information Webstart can permit its security managers loading of the native code.

Now for JInput: Due to the plugin design the plugin-jar and its native counterpart are not in the classpath of the runtime environment. They were added by jutils which belongs to the application.
I think that webstart considers the application untrusted even if it was signed and the user confirmed his/her trust for it.

This is only speculation but it makes sense for me. I will try to setup some configurations on my machine to see if I can get around this security restriction. I'll tell you if I am successful ...


--- EDIT
The Security Exception occurs only when the plugin and the jinput/jutil stuff is installed as extension. Regardless whether they are available through JNLP, too.

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #22 - Posted 2003-09-28 21:53:05 »

I used BeanShell for 'live' poking around with webstart and jinput and that helped a lot. For further explanations I have to define two terms:

I consider a library installed when it is available in the ext folder of the running JVM.

A library is deployed when it is made available through the JNLP tag 'jar' or 'nativelib'. Because of the Java class loading mechanism one should know that having the same class available via extension and JNLP the class is always loaded from the file in the ext folder (short: installation overrides deploying).

All explanations assume to have the jinput plugin installed in ${java.home}/lib/controller (deploying is currently impossible!).

With the jinputtester and webstart it goes like this:

a) jinput.jar and jutils.jar are installed:
All classes are taken from the installed version of jinput because Java's classloaders have to ask their parent class loaders first to find a class data. Because of the things I explained in the last post a security exception is thrown.

b) jinput.jar and jutils.jar are deployed:
Jinput finds (for example) dxplugin.jar in ${java.home}/lib/controller and lets jutils searching for suitable classes in this jar. When jutils finds a matching class file ("DirectInputEnvironmentPlugin.class") it generates a special class loader (PluginLoader) that can access all the files in dxinput.jar without explicitly specifying a parent class loader. This causes the usage of the SystemClassLoader. Anyway when defineClass() is called for DirectInputEnvironmentPlugin it fails (ClassNotFoundException) because it is unable to locate its parent class: ControllerEnvironment.

[This kind of exception wasn't mentioned before because I thought I did something wrong with the JNLP file.]

Java expects ControllerEnvironment to be accessable from the same classloader that tries to define DirectInputEnvironmentPlugin. This does not work because PluginLoader can only load classes that are inside the dxinput.jar and that are available to the SystemClassLoader.

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!
For those who don't know but try to follow this explanation: The context class loader is to be found via Thread.currentThread().getContextClassLoader() and specifies the class loader that generated the thread. For applications that were started from the commandline this is the same as the SystemClassLoader but for applications that were launched from webstart it is a special classloader.

The usage of the context classloader even fixes the security exception I got when having jinput/jutils installed.

After this long post I hope everyone who was involved understood the problem and how it was solved. If not I will try to explain further.

Finally here is my RFE: Please replace the creation of the PluginLoader in net.java.games.input.Plugins with this:

PluginLoader loader = new PluginLoader(f, Thread.currentThread().getContextClassLoader());

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline Jeff

JGO Coder




Got any cats?


« Reply #23 - Posted 2003-09-29 20:58:27 »

Quote

A program is started via webstart. The JNLP file specifies jogl.jar as jar-ressource and its native library in the native section.


Ah.  I see.  The issue here is that the plugin stuff specifically requires the plug-in's DLL to be in the same folder as the Plug-in's JAR.  This is to prevent name clashes in DLL names between different plug-ins written by different people at different times.

I'm not sure how to change this in a way that preserves the intent and works for JWS. Really, its a limitation in JWs thats the issue.

I'll try to get the JWS guys involved and see what we can come up with.

BTW guys, I'm going to be off in Wisconsin from Oct 3 through Oct 13 for my little brother's wedding.  I'll try to stay connected to you guys but my posting may be a bit spotty and my resources limited til I get back.

JK


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #24 - Posted 2003-09-29 21:23:29 »

Okay, I talked to the JNI guys.

I can add a property that you can set that will turn off the "getLibrary' override in the class loader for plug-ins.  This should let JWS go where it wants to for the library.

HOWEVER realize that this creates a potential problem for using independantly develoepd plug-ins together.  

The reason why "getLibrary" currrently points to the same directory as the one in which the plug-in jar is found is in order to make it possible to use plug-ins with conflicting names.  If you turn that off, then if two plug-in writers both named their DLLs something stupid like "input.dll" you will be unable to use both plug-ins at the same time.

Or in the more general case, any app that uses the plug in library which turns off this feature will not be able to use DLLs with name conflicts together.  (This is less likely a proiblem for JInput as it might be for somethign like an image mainpulation package or other "framework" type app that might have a great many plug-ins.)

That clear?

JK

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #25 - Posted 2003-09-30 16:24:09 »

Well? is everyone happy with this solution? If so I'll implement it.


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #26 - Posted 2003-10-02 00:57:53 »

Works for me.

Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #27 - Posted 2003-10-06 22:45:33 »

I regret it doesn't work. Special property was set. Plugin was delivered by JNLP as nativelib. The following code was tried:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
print(System.getProperty("net.java.games.util.plugins.nolocalnative"));
true

bsh % loader = new PluginLoader(new File("unused"));
bsh % print(loader.findLibrary("dxinput"));
null

bsh % contextLoader = Thread.currentThread().getContextClassLoader();
bsh % print(contextLoader.findLibrary("dxinput"));
E:\Dokumente und Einstellungen\RoB1\Anwendungsdaten\Sun\Java\Deployment\javaws\cache\http\DtheBohemian.dyndns.org\P80\DMjaws\RNjinput-plugin-win32.jar\dxinput.dll


The last command shows that finding the native library with the context classloader works. It seems that the current implementation isn't using its parent (which IS the context classloader) properly.

When plugin is already installed in lib/controller everything works fine as stated in my last post.

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline TheBohemian

Junior Member




Java will rule them all!


« Reply #28 - Posted 2003-10-06 23:09:54 »

Found out the following:
PluginLoader is using super.findLibrary() to retrieve the library's path when the special property is set. That's nice but none of PluginLoader's superclasses is delegating findLibrary to its parent.
To make things even worse the only implementation of this method exists in ClassLoader itself and it simply returns 'null'. Weird: It is impossible to call parent.findLibrary because it is 'protected'.

[In my previous post this was done by BeanShell using Reflection and disabled access restrictions.]


cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline Jeff

JGO Coder




Got any cats?


« Reply #29 - Posted 2003-10-07 15:34:44 »

Hmm.

Well, if the proper parent routine returns null then the logicc  inside of the classloader must be "if getLibrary returns null, then look in the default places."

I'm not entirely sure thats what we want. though, as I suspect doing so would defeat JWS's security restrictions.

Is it really not working if you put the lib file in the native declarations in the JNLP?  Thatw as my itnent, to make it work like all other JNLP apps with native code, which are required to do that.


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (12 views)
2014-09-21 23:33:17

BurntPizza (30 views)
2014-09-21 02:42:18

BurntPizza (22 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (28 views)
2014-09-20 20:14:06

BurntPizza (32 views)
2014-09-19 03:14:18

Dwinin (48 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!