ServiceBrowser in Head First Java using RMI

Has anyone else tried compiling/running the ServiceBrowser and ServiceServer from Chapter 17 of the Head First Java book? That is the only one I cannot get to function correctly.
It consists of the ServiceBrowser (client), the ServiceServer, the ServiceServerImpl, the various stubs/skeletions, and 3 small service programs all implementing the passing of a JPanel object (getGUIPanel). For ease, I put them all in the same directory to rule out various package or classpath issues and compiled the various classes. I have both typed it all in and downloaded the jar on the headfirstjava.com site under that book's link.
After everything is compiled, I open several dos windows and go to the directory containing everything for both client and server. I then run "rmiregistry" in the first one. In the second one, I run "java -classpath . ServiceServerImpl" and it says "Remote service running". It then returns to the command line making me wonder if it is missing a mechanism to keep running or if that is what is supposed to happen when you register a service. Finally, I run "java -classpath . ServiceBrowser" and get an exception at the Naming.lookup to "//127.0.0.1/ServiceServer" (the service was registered on there as ServiceServer).
Any help would be greatly appreciated...since I get the exact same error from the JAR, it most likely indicates that I'm doing something incorrectly w/r to the procedures, but I'm not sure and haven't been able to figure it out yet.
Thanks,
Ross

Poor me

I don't have a copy of that book

.
So I sent a heads up to Kathy Sierra. Maybe she will take pity on us and come talk to you

.
[ July 14, 2003: Message edited by: Cindy Glass ]

Howdy Ross,
Hmmmm.... you know, I'm racking my brain (painful, not recommended) trying to think of what is causing your command-line to return. The code does work if all goes perfectly according to plan

I suspect that you *might* have a classpath issue, because you probably have an IDE that's done something lovely with your system classpath. That's OK, because you're dealing with it when you run java using the -classpath flag, BUT that means the rmiregistry might not have access to those classes, and it needs to.
Two things come to mind:
1) Be sure that you cd to the directory where the classes are BEFORE running rmiregistry. I think you're already doing that.
2) Set your classpath in your DOS terminal *before* you run rmiregistry, if in fact you do not have the current directory (the .) in your classpath.
(OK, I've been on unix way too long -- I can't remember how to do this in DOS, but I think it's like:
SET CLASSPATH=.;%CLASSPATH%
rmiregistry
(hopefully you or someone else will know if my DOS syntax is right.)
3) The other thing that would help is if you *fix* something BAD that I did in the code. What I did doesn't stop it from working, but what I did might be *hiding* the problem that you're having... the BAD thing for which I should be beaten, is that I "ate" the exception in the main method of the server, where I do a try/catch to bind the server to the rmiregistry.
If you put :
catch(Exception ex) {
ex.printStackTrace();
}
That might give us a better idea about what's going on.
My suspicion is that the server isn't binding to the registry properly, and it might have to do with your classpath issue.
Try that... and since I already know that *you* are one who does whatever it takes to get things working, I'm sure we'll get to the bottom of this

Let me know!
cheers,
Kathy
perpetrator, "Head First Java"

Originally posted by Kathy Sierra:
perpetrator, "Head First Java"

Yep, it was apparently the classpath issue, as it worked fine this time and I seem to recall that back when I had posted the message, I didn't have "." in the classpath (remember when I wrote you about the serialVer, Kathy?).
I will be posting a review of this book on javaranch over the weekend, but for anyone perusing this message, don't wait---run out and buy it now if your skill level is anywhere between none and intermediate. The way Kathy and Bert conveyed information while building on what they taught, and their coverage of the MANY subtleties/peculiarities of the language makes it a must-read that will cement concepts in a way that few books can or will.

Ross