3 Replies Latest reply on Oct 3, 2002 3:37 AM by Christoph Grimm

    Running a non-web client, deployment issues

    Volkmar Newbie

      Hi everyone,

      I have been developing EJBs on SUNs j2ee server. Needless to say, I want to deploy on something better, thus chose JBoss. I am getting to grips with the deployment descriptors, and where to put files; to check again: I am supposed to put both the EAR and client JAR files into the deploy directories ?
      The point is that our application doesn't use web elements. It is Swing/AWT-based. The way we used to test it was to deploy [the EAR file presumably] the app to SUNs server, then call the client JAR with the 'runclient' command.
      There are two things I really need clarification on:
      1) The runclient command is actually a shell script which appearantly wraps a whole bunch of commands for convenience =>
      ACTIVATION=" -Dcom.sun.enterprise.home=$J2EE_HOME -Djms.home=$JMS_HOME -Djms.properties=$J2EE_HOME/config/jms_client.properties -Djava.security.policy=$J2EE_HOME/lib/security/
      client.policy -Djava.security.auth.login.config=$J2EE_HOME/lib/security/
      Is my understanding correct that there are JBoss equivalents for these arguments, so that it will run under JBoss ? I just cannot find the actual java command that runs our Swing client... The only hint is the variable "$JAVACMD" which is embedded in the 'runclient' command.

      2) If and when our application runs, where (in which machine's RAM) is the code executed ? Is it done remotely, so that each workstation just gets the stubs and then it all happens on the server, or are the java objects necessary to run the GUI exported to each workstation and then run there, with remote calls only to the beans on the server ? As you can see, my confusion stems largely from the fact that I don't quite understand how runclient works, which in turn prevents me from fully understanding the distributed nature of (non-web) j2ee apps :(
      Please help !

      Best regards,


        • 1. Re: Running a non-web client, deployment issues
          Adrian Brock Master

          Caveat, I have never used runclient.

          Unfortunatly JBoss doesn't have an equivalent of
          runclient. Also called Application Client in the J2EE
          spec. It is an optional and under-specfied part of J2EE.

          Basically an Application Client is a jar that can
          run in a mini Application Server and talk to the
          main Application Server(s). The spec
          requires all J2EE apis to be available, but the
          only required services are JNDI and Security.
          The client code has no restrictions
          on the operations it can perform, e.g. it is legal
          to System.exit();

          The bit that is missing from JBoss is the parsing
          of the client deployment descriptor on both the
          client and server.

          Since JBoss is highly modularised you can construct the
          equivalent of an Application Client yourself.
          The minimal config included with JBoss3 would be a start,
          it is just JNDI and JMX.

          You could add as many or as few other services as you
          like, e.g. managed connections.

          The only downside is that it won't be portable to other
          App Servers if it isn't based on the client deployment

          I did see a post once that somebody had done just this
          (it might even have parsed the client descriptor?)
          But it wasn't contributed back to the JBoss codebase :-(

          The answer to your specific questions are that the
          client code runs locally, but it has remote
          access to the Application Server(s) through the normal
          jndi lookups and a java:comp namespace.


          • 2. Re: Running a non-web client, deployment issues
            Christoph Grimm Newbie

            to deploy a gui client fist of all you need a properties file named jndi.properties with the following content:


            add this file to your application jar

            to load the context, do the following

            Properties jndiProperties = new Properties();
            jndiProperties.load( getClass().getResourceAsStream("/jndi.properties") );
            InitialContext ctx = new InitialContext( jndiProperties );

            then you need to add some jar files to your classpath:
            ( and also to include them in the client distribution )


            (if there are others needed for a basic client someone could pls. corrrect )

            to start a client you can use three different ways:

            a) create a script file that sets your classpath and starts your gui main class

            b) in your application jar file use the manifest to set the classpath and the main class and execute the jar directly ( in M$-OS you can even link the jar extension to java so one only needs to click on the jar file )

            c) use java-webstart to launch your gui. beware that if your gui need's to access restricted resources, you have to sign all the jar files mentioned above.

            btw. i thing the main problem with the sun ri is that it makes people think they know about j2ee when they have sucessfully clicked the right buttons.
            the advantage of jboss is, that you have to read and understand the j2ee specs at least to some part to write the descriptors ;-)

            • 3. Re: Running a non-web client, deployment issues
              Christoph Grimm Newbie

              i forgot one issue:

              jboss does not use stubs generated in advance and ditributed with the client, but so called dynamic proxies.
              these are downloaded to the client at runtime by the RMIClassloader

              therefor you have to create a policy file like client.policy

              with at least this minimal content:

              grant {
              permission java.security.AllPermission;

              your client must be started with the following option:

              if you use java-webstart instead, put the following in your jnlp file


              and beware to sign all your jars