Hi all,
The following notes is from a tutorial by sun.
My question is, if we have to copy the EAR file to the client, don't we lose the advantages of a thin client(as we have to update the ear file every time the ear file changes)? Why do we need an EAR file if we have the client jar which has the client stubs..
Thanks,
Chandana

Accessing a Remote Server
If the J2EE application client will reside on a different machine than the J2EE server, before executing runclient you must do the following:

Install the J2EE SDK on the remote client's machine. The SDK must be on the client's machine so that you can run its runclient script. You do not need to start the J2EE server on the client's machine.
Copy the EAR file to the remote client's machine.
Copy the client JAR stub file to the remote client's machine.
Set the APPCPATH environment variable to the name of the client JAR stub file.
Set the VMARGS environment variable to the following value:
-Dorg.omg.CORBA.ORBInitialHost=<remote-host>



For example, if the remote host were named murphy, you would set the VMARGS variable on a Windows machine as follows:

set VMARGS=-Dorg.omg.CORBA.ORBInitialHost=murphy

That's a mistake. You dont need to deploy the EAR. You will however just need to make sure the client JAR contains all the client container classes you need.

Dave Wolf
Personified Technologies

That 99% of all documentation and discussion about deploying J2EE apps assume you are using a web-app, and so you typically have the web/servlet layer and the EJB layer deployed on the same machine, and maybe use clustering. Or maybe different machines on the same network, so copying bug huge EAR files is no big deal.

When you have a desktop application, you must do as the previous poster said, which is to include the container classes needed by both client and server. This is not always simple and depending on your design, can be very difficult. The main problem is that javac is not always 100% accurate when determining the actual runtime dependencies between classes. Additionally, since you can dynamically load classes, javac has no way to even tell what classes you might need.

The only way to do it is to keep yourself organized during development and keep client classes, server classes, and classes needed by both client and server all seperate. Even that is not ideal.

It would be cool if the J2EE spec included some sort of dynamic by-class networked class loading mechanism. Webstart is OK, but it is by-jar and it is manual to set up on the server.

Dave