Like the title says.
If i use a button to trigger a change of screens with “gotoScreen” the applet crashes with the following exception:
Exception in thread "LWJGL Renderer Thread" java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkMemberAccess(Unknown Source)
at java.lang.Class.checkMemberAccess(Unknown Source)
at java.lang.Class.getDeclaredMethods(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Using a Panel with an Interaction element works fine. So the problem is probably within the ButtonControl class or something similar
Don’t know if could work, or if it could efficient, but maybe try to use a hide/show if you’re only switching from one panel to the other?
OTOH, if you want to completely change screen, that wouldn’t work.
looks like a java sandbox error, seems like nifty is trying to do something that requires out of sandbox perimission, is the nifty jar signed?
I can live with the exception, and work around it if i have to.
What bugs me is that pressing a button works fine, and changing screens work fine. I can however not use a button to change screens.
To me it sounds like a bug, or something that can be fixed in the core.
Edit: and yes, it’s a sandbox security exception. I just get the impression it doesn’t have to be triggered.
Doing some testing here with my nifty and it seems when assetManager gets a call nifty (or whatever) is entering in an unending loop. Unsure.
Does that have a relation with what you’re experiencing? Probably not, but it’s possible, even remotely.
Just a bump to see if this might catch the attention of @void256
Is this something that is “fixable” (should it be?), or should i go ahead and try to create my own Control to handle this?
Well, Nifty requires reflection to connect any onClick() definition in the xml with the actual method on the ScreenController class. Looking at the initial exception you’ve posted your applet seems not to have the permission to actually let Nifty to find about all the methods via the Class.getDeclaredMethods() call. I’m no Applet or Java Security expert to give any hints on what you might do, to allow this.
What confuses me now, is, that you said in a later post that onClick() events DO work when you don’t change screens in an onClick(). I don’t understand that because it is using the same de.lessvoid.xml.tools.MethodResolver to do the actual call o_O
Do you get the same exception in any onClick() call that does work?
Yes, it’s confusing, isn’t it?
I only get the exception when a ButtonControl’s onClick() is used together with gotoScreen().
Now i use a Label with onClick(), which is working fine. So this is probably the approach i’ll have to take for now.
I also use reflection a bit to create dynamic classes, so i don’t think that’s it.
TBH, now that i think of it. When i change screens, i also change the Controller class as i have one controller per screen.
Label+onClick()+gotoScreen() = OK!
ButtonControl+onClick()+gotoScreen()= NOT OK!
I can’t imagine what might cause this exception when changing screens or changing controllers o_O because basically there is not really much different. the exception itself really is non-ambiguous tho.
is there any chance that you can build a minimal test program for this? really reducing it to the minimal xml/code to reproduce the problem and then sending something I can build and test here?
I don’t have any other idea right now
It seems reflection is not allowed to be used inside applets.
But from what rickard said it seems like its possible in some cases (?)
Reflection is IMHO not allowed in applets so it’s very strange that it works in some cases o_O
Signing the applet and using a policy file to allow reflection should solve this for all cases but I’m no expert in applets
And I’m still interessted in figuring the difference out but as I’ve said, currently this is an amazing effect
Strange indeed. I’ve used an unsigned applet for quite a while now, with several testers (both now and before switching to jme), and no problems with the reflection methods i use (getConstructor and newInstance). And nifty is working alright as well, apart from this case.
I’ll see if i can put together a test case. Meanwhile, some more info i thought of: When i switch screens, i also switch controller class ( i use one class per screen in an attempt to be a bit more OO).
Yes, you’ve mentioned your usage of several ScreenController classes before. I can’t relate that (yet) to your reflection problem There must be a relation however because you said it works without it, right?
I’m looking forward to some test case example to analyze this further!
Using multiple screen controllers is working fine, it’s just ButtonControl that doesn’t.
it doesn’t matter because in the end it still goes through the NiftyMethodInvoker which uses reflection.
I want your applet test case!