6 Replies Latest reply on Oct 2, 2006 9:28 PM by warrenc5

    Problem accessing remote home interface via RMI/IIOP

    stevenettles

      I successfully deploy a Stateless Session Bean in JBoss with iiop invoker (ServerBean, Server, ServerHome). In examples that I have seen the following is performed in client code to perform a lookup in jndi and to return the remote home interface:

      InitialContext context = new Initial Context( jndiProps );
      ServerHome home = (ServerHome) Portable.RemoteObject.narrow( context.lookup(
      "iiop/org/amd/catalyst/iiop/server/Server" ), ServerHome.class );

      However, when I perform this in my client, I get a ClassCastException. If I don't do the "narrow" and simply return an Object from the context.lookup, I can see that an object of type org.omg.stub.javax.ejb._EJBHome_Stub is returned. If I do a toString on this object, I can see that it is the IOR of my ServerHome (which I can see when my .jar is deployed). I am unsure how to proceed since I can't narrow the stub to a ServerHome and I can't invoke a create() method on it.

        • 1. Re: Problem accessing remote home interface via RMI/IIOP
          reverbel

          The Portable.RemoteObject.narrow call is required for IIOP. It attempts to load a suitable stub class, which in your case would be named _ServerHome_Stub. The ClassCastException probably means that narrow was not able to load the stub class.

          JBoss makes IIOP stub classes avalilable to clients through HTTP. If you use an IOR parsing tool (such as JacORB's dior or MICO's iordump) to inspect your EJBHome's IOR (which should have been printed out by the JBoss server), you should see a Java codebase tag like

          http://host.name:8083/WebCL[org/amd/catalyst/iiop/server/Server]/

          If _ServerHome_Stub.class is not locally avaliable in the client's CLASSPATH, the narrow call will attempt to download this class from the codebase included in the IOR. Make sure the java.policy file at the client side grants your client permissions to download stub classes from that codebase. (Does the the problem persist if you grant allPermission to the client?)

          Cheers,

          Francisco

          • 2. Re: Problem accessing remote home interface via RMI/IIOP
            stevenettles

            The comment about JBoss making IIOP stub classes available through HTTP was not clear to me (although I did use JacORB dior to inspect the IOR of my EJBHome...which indeed had a Java codebase tag as you described). My assumption was that a _ServerHome_Stub object would be returned rather than a _EJBHome_Stub object. I understand that _ServerHome_Stub is not in the client classpath (although _EJBHome_Stub.class is in jbosall-client.jar and perhaps other client jars). Therefore, it makes sense that the client would somehow need to load the dynamically generated _ServerHome_Stub. I just didn't understand how the client downloads stub classes from that codebase via HTTP and the implication (if any) to the client code. By the way, I had a client.policy file in my classpath that looks like:
            grant {
            Allow everything for now
            permission java.security.AllPermission;
            };

            Is this what is required when you mentioned making sure the java.policy file at the client side grants client permission to download stub classes when allPermission is granted?

            It sounds like my client can not download _ServerHome_Stub class and as a result the client is receiving _EJBHome_Stub instead. Is this correct? If so, what else should be done to ensure that the client can download the stub class?

            Regards,

            Steve

            • 3. Re: Problem accessing remote home interface via RMI/IIOP
              reverbel

              Stub downloading is automatic and has no implications to the client code.

              Yes, I meant something like you did in you client.policy file. After things are working you might want to grant more specific permissions. (AllPermission should work, but it is overkill.)

              Note, however, that the client.policy file should be exposed to the client through the java.security.policy property (use a command line switch like "-Djava.security.policy=./client.policy") rather than in the CLASSPATH.

              The shell script in the attachment can be used to start some.iiop.client on Linux/Unix. (It assumes that JBOSS_HOME is set and that a suitable client.policy is in the current directory.)

              Cheers,

              Francisco

              • 4. Re: Problem accessing remote home interface via RMI/IIOP
                dthenar

                 

                "reverbel" wrote:

                \[...]

                JBoss makes IIOP stub classes avalilable to clients through HTTP. If you use an IOR parsing tool (such as JacORB's dior or MICO's iordump) to inspect your EJBHome's IOR (which should have been printed out by the JBoss server), you should see a Java codebase tag like

                http://host.name:8083/WebCL[org/amd/catalyst/iiop/server/Server]/

                [...]

                Cheers,

                Francisco


                Is there any way to force JBoss to push the stub via IIOP? I have a security requirement to use IIOP only.

                Thank you,
                John

                • 5. Re: Problem accessing remote home interface via RMI/IIOP
                  reverbel

                   


                  Is there any way to force JBoss to push the stub via IIOP? I have a security requirement to use IIOP only.


                  No, there is not. Stub dowloading is via HTTP only.

                  Note, however, that stub downloading happens only if the stub is not available at the client side. If, for security reasons, you do not want stubs to be downloaded, then you can always put rmic-generated stubs in the client classpath.

                  Francisco

                  • 6. Re: Problem accessing remote home interface via RMI/IIOP
                    warrenc5

                    I had the smae problem until I put

                    "$JBOSS_HOMEclient/logkit.jar"
                    "$JBOSSLIB/jacorb.jar"
                    "$JBOSSLIB/commons-logging.jar"
                    "$JBOSSLIB/avalon-framework.jar"


                    in the client classpath