Figure A−20: The "final check" dialog you see before committing to the deployment Now you will see a progress dialog like that shown in Figure A−21...

This dialog gives you feedback about what is happening in the deployment process. The two columns on the left show progress information while the text area on the right shows the current step being performed. If there is any error during this process, you will see the error message in this text area.
671
Appendix A: Installing the J2EE Reference Implementation Figure A−21: Progress dialog showing the out−put of a successfully completed deployment Updating beans after you have deployed them
It is inevitable that you will need to update beans after that initial deployment. For example, there is no way to debug the bean implementations without deploying them first. If you had to go through the full deployment process each time you changed the bean code, it would quickly send you insane! Luckily the deployment tool provides a shortcut to redeploying existing beans.
After you have made your changes to the code, recompile it. In order for the deployment tool to update the code, you need to inform it that you have changed something. Select the Update Files option from the Tools menu. The deployment tool will now go away and check which files have been changed and present you with a dialog that names all the changed files. Click OK to continue. Now, you must save the application again.
This is an extremely important step. If you do not explicitly save the application after the update step, the tool will redeploy the old code, not the new files. We believe this is a bug as it appears the tool is fetching the update from the file on disk, but does not do an implicit save of the changed file before reading the file off disk to do the deployment with. If you wish to re−verify the application/bean before redeploying, you will also need to save the file.
Updating the application on the server is now just a matter of selecting the Update and Redeploy option from the Tools menu. You should now see the same dialog as you saw back in Figure A−21 as the deployment process proceeds.
Running a client application
Client applications for a J2EE server and EJB can come in one of two forms — a standalone client, or a client that is also part of the J2EE environment (for example a servlet or JSP).
Running standalone clients
A standalone client is an application that will run on the command line. These applications do not require the use of a full environment. However, in order to access the EJB, you will still need to do a small amount of work to allow the application to function correctly.
Running a standalone application still needs access to the client stubs of the EJB. While you might be tempted to solve this by just including the path to the client JAR file in your CLASSPATH setting, that is the wrong way to solve the problem. The big issue here is that your application makes use of JNDI to find beans, so how do you get the JNDI system correctly configured in the first place? To get the environment going, you will need to create an application that resides as part of the EJB/J2EE environment — that means using the 672
Appendix A: Installing the J2EE Reference Implementation deployment tool, even for standalone applications.
To create an deploy a standalone client, in the deployment tool, you use the New Application Client option under the File menu. The steps look reasonably similar to the EJB deployment steps. Select the collection of classes and JAR files you need, and any beans you are going to reference. Once that is complete, save and deploy the client application.
Tip
The deployed application client will still use the local CLASSPATH setting. That means you only need to provide a simple boostrap class in the application client and then leave the rest of your client code on the local disk. Only registering the stub file will save you needing to re−deploy the entire application every time that a file changes.