Client Error (7 posts)

Topic tags: connection, error, networking, spidermonkey, stack trace
  • Profile picture of bubby4jj bubby4jj said 7 months, 3 weeks ago:

    Exception in thread “LWJGL Renderer Thread” java.lang.ExceptionInInitializerError
    at com.jme3.network.base.MessageProtocol.messageToBuffer(MessageProtocol.java:75)
    at com.jme3.network.base.DefaultClient.send(DefaultClient.java:213)
    at com.jme3.network.base.DefaultClient.start(DefaultClient.java:147)
    at Bubby4j.BaseGame.connectToServer(BaseGame.java:255)
    at makeza.client.Main.simpleInitApp(Main.java:57)
    at Bubby4j.BaseGame.initialize(BaseGame.java:196)
    at com.jme3.system.lwjgl.LwjglAbstractDisplay.initInThread(LwjglAbstractDisplay.java:124)
    at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:200)
    at java.lang.Thread.run(Unknown Source)
    Caused by: java.security.AccessControlException: access denied (java.lang.reflect.ReflectPermission suppressAccessChecks)
    at java.security.AccessControlContext.checkPermission(Unknown Source)
    at java.security.AccessController.checkPermission(Unknown Source)
    at java.lang.SecurityManager.checkPermission(Unknown Source)
    at java.lang.reflect.AccessibleObject.setAccessible(Unknown Source)
    at com.jme3.network.serializing.serializers.FieldSerializer.initialize(FieldSerializer.java:83)
    at com.jme3.network.serializing.Serializer.registerClass(Serializer.java:179)
    at com.jme3.network.serializing.Serializer.registerClass(Serializer.java:145)
    at com.jme3.network.serializing.Serializer.(Serializer.java:127)
    … 9 more

    What’s this mean? All I’m doing is connecting successfully:

            try {
            Client myClient = Network.connectToServer(host, port);
            myClient.start();
        } catch (IOException ex) {
            System.out.println("Could not connect to Host: " + host + " Port: " + port + " Cause:");
            Logger.getLogger(BaseGame.class.getName()).log(Level.WARNING, null, ex);
        }
    #
  • Profile picture of pspeed pspeed815p said 7 months, 3 weeks ago:

    The serializer requires direct access to the message/object fields when serializing. So it tries to setAccesible() in the fields which requires elevated security permissions.

    What environment are you running your client in?

    #
  • Profile picture of Momoko_Fan Momoko_Fan371p said 7 months, 3 weeks ago:

    IMO It should still work even if running in a restricted environment. Currently jME3 applet deployment runs without elevated permissions. For serialization to work however, it requires all the fields in a message and the fields inside objects to be public.

    #
  • Profile picture of pspeed pspeed815p said 7 months, 3 weeks ago:

    It’s a nice idea and maybe setAccessible() is smart enough to know whether the field is public or not… but FieldSerializer will always call it whether the field is already public or not. Not only that, the built in messages have always had private fields… and at least one of those is used internally to SM during connection setup, and always has been.

    Whatever environment the poster is running in, it has not elevated the java.lang.reflect.ReflectPermission suppressAccessChecks permission.

    #
  • Profile picture of bubby4jj bubby4jj said 7 months, 3 weeks ago:

    I’m running it in a Java Applet, I’m not sending any messages. I don’t do anything with the connection after the try/catch block. So how do I fix it? Or is it a bug with jme3 itself?

    #
  • Profile picture of pspeed pspeed815p said 7 months, 3 weeks ago:

    There are messages sent back and forth to establish the connection. So simply connecting to the server will send a few messages.

    I’m not sure what the best way to proceed is. I don’t know if its even possible to raise the permission level of an applet as it’s been so long since I messed with them. That would be the easiest way if its possible.

    We could potentially fix this in JME but none of the options are particularly pleasant. As a work around, you could write your own serializer for the messages in question (com.jme3.network.message.ClientRegistrationMessage and DisconnectMessage) to use the getters/setters instead of direct field access. But that’s rather unpleasant on your end.

    I think the right solution is to have JME fall back on the getters and setters when it is unable to reset the access of the field directly… but I have no time to make this change today.

    #
  • Profile picture of bubby4jj bubby4jj said 7 months, 3 weeks ago:

    Ok, thanks.
    I’ll try using kryonet for now.

    #