This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have the same problem about db classes available to the client in standalone mode. In RMI server mode the client does not need the db classes, but in standalone mode the client accesses the server db classes. Is this right or not. For that I put the server.jar in the classpath of the client. Thanks for your advices. Charles
You will put some of the db package classes in your client.jar. You will need them for Local mode. You will also hav ethe _stubs from the server also in your client.jar Zhou - Yes there are only two jars client.jar and server.jar, there is no db.jar unless you want to call your server.jar db.jar, which I think is a misnomer. Mark [ December 10, 2002: Message edited by: Mark Spritzler ]
Joined: Oct 18, 2002
Mark, As you say we need the stub implementation in the client jar, otherwwise it does not work, the RMI connection sends a Remote Exception. But how comes the stub must be in the client jar. Why isn't there a complete separation possible between client and server in remote mode? (interface in the client and implementation of the stub in the server). Sorry if this question looks stupid but I need an explanation here. Thanks, Charles.
Charles, the reason is simple. In this assignment we are not using Dynamic Downloading of stub classes. In order to do that you would need a web server. Which of course most people don't keep in their back pockets. So then the class would need to be accessible to the client, and the client.jar is the best place for this. Mark
BTW, I personally submitted three jars: a client, a server, and a shared jar with all the shared classes needed by both client and server. The Class-Path manifest attribute will glue the jars together. - Peter