21 May 1999
1. Using JavaDoc.
a. The @serial tag should be inserted in the comment
for any instance field to allow the serializable fields tables to be generated.
b. If you want any blank lines to appear between sentences,
you have to use a <p> tag as JavaDoc will ignore blank lines.
c. I tried inserting the PRE and POST comments inside
the methods but JavaDoc did not use them. Once I moved the comments into
the method description comment, JavaDoc used them.
7 June 1999
1. Java Bean Box Trouble with CLASSPATH. I found that the Bean Box had problems with the CLASSPATH setting in that if the CLASSPATH includes the CosmoPlayer classes jar path it caused the Bean Box to be unable to complete the generating adapter classes.
2. Jerry Loyd lesson on using Java Bean in Borland
Builder.
" Subject: JBuilder and installing
beans
I found the problem, and it may be of interest to
everyone. JBuilder was not able to use a bean that has
not specified a
'package' name. To get the Core Java Book "RangeBean"
sample to work, Iadded a 'dummy' package name to the two .java files making
it up,
recompiled, and then put them into a .jar file. When
I installed the .jar file into JBuilder, the components showed up as 'dummy.RangeBean'
and 'dummy.IntTxtFld' (or whatever it was...) When I dragged-and-dropped
the bean onto a panel, Jbuilder added the following line of code to my
source file: import dummy.*; This compiled and ran just fine. So, to ensure
that at least *one* of the major Graphical IDE's can use your bean, be
sure to define a package name for it. Jerry Loyd
3. Wong's Bean Tips.
Subject: Some BDK BeanBox tips.
Hi people, Thought I'd share some tips with those who
are/will be playing with BDK BeanBox so that you won't have to lose too
much hair. 1. If you are making a bean and want to see the changes made
to
it, it seems you have to restart beanbox to reload the
jar or the changes won't show. 2. If you are using other packages in your
bean such as Swing 1.0.1, make sure the beanbox invocation environment
has the correct classpath to the package. In my version of BDK(Feb 98),
the beanbox is started through a batch file, run.bat. It wipes out your
default CLASSPATH so you will have to modify the file to include the current
%CLASSPATH% if you have anything in your bean that requires it. Wing Keong.
4. Loyds Tip on storing GIF IN BEAN
Subject: Wrapping images into beans, the answer
Many thanks to Wing Keong. This less-than-obvious approach
worked like a charm. Jerry Loyd
Try getSystemResource() from ClassLoader. It works for
me. Wing Keong.
I am trying to make a bean that uses a .gif file in its
display. I can't seem to figure out how to store images inside a bean.
All of the 'setImage' methods I've tried require a path-name to a file.
Even if I manage to wrap that file into my bean's jar, the system then
looks at the computer's file directory, instead of into the bean, to find
the file. It seems I need to find a way to do one of the following: 1)
Force JAVA to look into the bean 2) Store images in a class or object somehow,
inside my bean If anybody has solved this problem, I'd sure like some pointers
on where to get started. Best regards, Jerry Loyd
5. Subject: Re: making jars
Dr. Keuneke, I have tried some Java Bean examples and
they all worked fine for me when I tried to incorperate them into the BeanBox.
Here are the steps I would do for each Bean I would like to put into the
BeanBox environment:
1. Assume that my root directory is C:\BeanStuff, I create
the following subdirectories: (I work on PC with Windows 95)
C:\BeanStuff\sun\beanbox\beans The *.java files are at
C:\BeanStuff
directory. For this example, let's say I would like to
have MyFirstBean
class to be incorperated with the BeanBox environment.
2. Declare the following package statement at the beginning
of the MyFirstBean.java file:package sun/beanbox/beans
3. Create the manifest file with the following content:
Manifest-Version: 1.0
Name: sun/beanbox/beans/MyFirstBean.class
Java-Bean: True
4. While at C:\BeanStuff, I compile MyFirstBean.java
with the following command: javac -d . MyFirstBean.java The -d option tells
the Java compiler to place MyFirstBean.class in its proper subdirectory
as indicated by the package statement. The . indicates that the current
directory is the package root.
5. Create the JAR file for MyFirstBean.class with the
following command: jar cfm MyFirstBean.jar manifest_file \
sun/beanbox/beans/MyFirstBean.class
6. Copy MyFirstBean.jar to the BeanBox BDK's jars subdirectory.
On my PC system, the BeanBox BDK is installed at C:\BDK. So I would copy
MyFirstBean.jar to the BeanBox BDK location as:
copy MyFirstBean.jar C:\BDK\jars\MyFirstBean.jar
7. Start the BeanBox and MyFirstBean should be listed
in the BeanBox's ToolBox window. These are the steps that worked for me
when I would like to add a Bean to the BeanBox. I hope these steps might
offer some help to your problem. I will try to work with YesNoDialog today
when I get home to see if I can get it into the BeanBox. Thanks, Veasna
> > Has anyone else tried to make a jar out of the YesNoDialog > class
in the Java In a Nutshell book? > > I did, what I thought was, everything
correct, but when I > try to put it in a beanbox it says that the jar file
> didn't have any beans! I made the manifest and had the > Java-Bean: True
> line with the right class????? > > I even edited it to make it implements
Serializable... > > Has anyone else tried? > > I did
the same with the Acme06Bean in the tutorial at > http://www.ecst.csuchico.edu/~amk/foo/java.tutor/beans/Beans2/properties.html
> > I get the same error with it. Sigh > > Anne >
18 June, 1999
1. JAVA BEANS. I am having troubles with null pointer exceptions when using Image class objects. I know they are not serializable and I thought I took care of it in the readObject() method.
2. I changed the SimStick to use direct drawing rather than an off-screen Image buffer, but know I see that the BeanBox can only make the canvas bigger and bigger. I cannot reduce the size of the SimStick in the bean box. I then changed from a Canvas class to a Panel class and found that the BeanBox can resize this both larger and smaller. The Spectrum example from the JavaBeans ground up book is a Canvas and it also can only get bigger, not smaller. SO I GUESS THIS IS A BEANBOX BUG. The class resizes ok when put in an application window as a Canvas. THE DRAWBACK- only Canvas can force its size into Panel. A panel put into another panel in BorderLayout NON-CENTER position is squeezed out if there is a center component. You would have to use a gridbaglayout I guess.
A Component object has the same problem as the Panel. Also, the BeanBox seems to draw this with more flashing in the display updates. And the setSize() doesnt seem to work when the object is loaded by the Bean Box.. You have to manually size it so it becomes visible.
3. The Image version of the SimStick bean has a problem with re-creating the bufImg and bufG instances. I put a repaint command in the readObject() method after setting the initialize flag = false, but it doesn't seem to be used. Tried manually setting the bufImg and bufG to null in the readObject() method, didnot work. Finally, I went to the paint() method and added a conditional test for either bufImg or bufG equal to null, to call the initialize() function. This seemed to fix the problem with the beanbox. I have to assume that the beanbox is either not using the readObject() method or at the time this method is executing, the object cannot handle a repaint request correctly.
I put a println call in the readObject() method and did
not see anything print out when I loaded the serialized object from the
file into the bean box. So I guess the readObject() function is not called
by the BeanBox. Component still has flashing even with an off-screen buffer
Image. This means I will have to stick to a Panel object.
Note: The applet that the beanbox built worked OK even
when the BeanBox could not load the saved bean itself.
4 July 1999 JAVA JDBC & ORACLE
1. I learned that the user name is not case sensitive
in the connection instruction.
DriverManager.getConnection ("jdbc:oracle:thin:@typhus.ecst.csuchico.edu:1521:ELI","user",
"password");
However, using the SqlPlus8 it is.
2. I learned that you cannot create a table if one of the same name already exists.
3. I learned that you have the have the full IP address in the getConnection() method. Cut and paste can be lethal.
4. I Learned that the SQL statements are not case sensitive. DROP TABLE JOLTDATA is the same as DROP TABLE joltdata is the same as DROP TABLE JoltData.
16 July 1999 JAVA JDBC & ORACLE
1. I learned that with a prepared statement you have to make sure that your string field is exactly the number of characters that you defined the column for if doing a compare against it. If not, you get nothing back from the prepared statement query as there will be no match. For example, I had defined the TYPE column to be CHAR(30). When I used String type = "Fighter" for my prepStmt.setString(1,type), I got no matches back from the query. I had to make sure the string was defined as = "Fighter "; to get this to work when doing unit testing of the method findByType(). The string had to be exactly 30 characters in length (not including a null terminator). The CHAR(30) declaration in Oracle indicates that there are exactly 30 characters not including a null terminator (which I am not sure applies to JDBC or Oracle). This is why you use a selection list using the results of a find on types for the query dialog. A SELECT type will return types of CHAR(30) so it is safe to turn these around for use in another query.
29 July 1999 JAVA RMI
1. I tried to run the Hello example from class but got
the following error message.
HelloImpl err: access denied (java.net.SocketPermission
127.0.0.1:1099 connect,resolve)
java.security.AccessControlException: access denied (java.net.SocketPermission
127.0.0.1:1099 connect,resolve)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:195)
at java.security.AccessController.checkPermission(AccessController.java:403)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkConnect(SecurityManager.java:1021)
at java.net.Socket.<init>(Socket.java:258)
at java.net.Socket.<init>(Socket.java:98)
at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:29)
at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:124)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:497)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:194)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:178)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown
Source)
at java.rmi.Naming.rebind(Naming.java:165)
at examples.hello.HelloImpl.main(HelloImpl.java:28)
I think this was because the JDK 1.2.2 has a more strict security manager than JDK 1.1 and I have to do some extra stuff having to do with specifying paths and policy files for the security manager, registry server, code bases etc.
So I then specified the parameters for the rmi.server.codebase and hostname and policy.
java -Djava.rmi.server.codebase=file:/d:/courses/Csci397C-24/RmiTest/
-Djava.rmi.server.hostname=john_i
-Djava.security.policy=d:/courses/Csci397C-24/RmiTest/policy
examples.hello.HelloImpl
and it seemed to work with console output
> HelloServer bound in registry
But then I tried to run the HelloApplet and got an error
output on the Java Console of:
HelloApplet exception: security.Couldn't connect to 'john_i'
with origin from ''.netscape.security.AppletSecurityException: security.Couldn't
connect to 'john_i' with origin from ''. at java.lang.Throwable.<init>(Compiled
Code) at java.lang.Exception.<init>(Compiled Code) at java.lang.RuntimeException.<init>(Compiled
Code) at java.lang.SecurityException.<init>(Compiled Code) at netscape.security.AppletSecurityException.<init>(Compiled
Code) at netscape.security.AppletSecurityException.<init>(Compiled Code)
at netscape.security.AppletSecurity.checkConnect(Compiled Code) at netscape.security.AppletSecurity.checkConnect(Compiled
Code) at netscape.security.AppletSecurity.checkConnect(Compiled Code) at
java.lang.SecurityManager.checkConnect(Compiled Code) at sun.rmi.transport.tcp.TCPEndpoint.<init>(Compiled
Code) at sun.rmi.registry.RegistryHandler.registryStub(Compiled Code) at
java.rmi.registry.LocateRegistry.getRegistry(Compiled Code) at java.rmi.Naming.getRegistry(Compiled
Code)* at java.rmi.Naming.lookup(Compiled Code) at examples.hello.HelloApplet.init(Compiled
Code) at netscape.applet.DerivedAppletFrame$InitAppletEvent.dispatch(Compiled
Code) at java.awt.EventDispatchThread$EventPump.dispatchEvents(Compiled
Code) at java.awt.EventDispatchThread.run(Compiled Code) at netscape.applet.DerivedAppletFrame$AppletEventDispatchThread.run(Compiled
Code)
Even after I modified the html to:
<applet codebase="D:\\courses\\Csci397C-24\\RmiTest"
code="examples.hello.HelloApplet"
width=500 height=120>
</applet>
OK - Finally got the HelloApplet to work (using appletviewer) by changing the html to:
<applet>
code="examples.hello.HelloApplet"
width=500 height=120>
</applet>
Apparently, the appletview was already using the current directory as the starting code base. Specifying the codebase in the html resulted in a final codebase path = D:\courses\Csci397C-24\RmiTestD:\courses\Csci397C-24\RmiTest from which it was impossible to find the HelloApplet.class file. Including or not including the parameter -Djava.rmi.server.hostname=john_i in the HelloImpl call did not seem to make any difference to appletviewer. However, nothing seemed to be able to make Netscape Communicator 4.61 work. I guess the security is just too good. Given the amount of time left in the course, I will not be able to spend any time fighting the Applet vs. RMI problems. This means my final Lab 4 will have to be a Java application.
30 July 1999 JAVA RMI - What you need to do to get JDK 1.2.2 RMI working.
The following is a summary of what I did to get a NON-Applet RMI example to work under JDK 1.2.2. Note: I chose a non-applet example because I think Netscape security will not allow you to use RMI even though the Java appletviewer can run an RMI applet. The example is the Hello example modified to run as an application as opposed to an applet. It just outputs the hello string received from the server to the console display. For the purposes of the lab, an applet based lab is not required and not desired due to the additional complexity.
HERE IS THE CODE I USED:
/* The file simple/hello/hello.java
*/
package simple.hello;
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface Hello extends
Remote {
String sayHello() throws RemoteException;
}
/* The file simple/hello/HelloImpl.java
*/
package simple.hello;
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
import java.rmi.server.UnicastRemoteObject;
public class HelloImpl extends
UnicastRemoteObject
implements Hello {
public HelloImpl() throws RemoteException
{
super();
}
public String sayHello() {
return "Hello World!";
}
public static void main(String
args[]) {
// Create and install a security
manager
if (System.getSecurityManager()
== null) {
System.setSecurityManager(new
RMISecurityManager());
}
try {
HelloImpl obj = new HelloImpl();
// Bind this object instance
to the name "HelloServer"
Naming.rebind("HelloServer",
obj);
System.out.println("HelloServer
bound in registry");
} catch (Exception e) {
System.out.println("HelloImpl
err: " + e.getMessage());
e.printStackTrace();
}
}
}
/* The file simple/hello/HelloClient.java
*/
package simple.hello;
import java.rmi.Naming;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
public class HelloClient {
public static void main (String
args[]) {
String message = "blank";
// "obj" is the identifier that
we'll use to refer
// to the remote object that
implements the "Hello"
// interface
Hello obj = null;
if (System.getSecurityManager()
== null) {
System.setSecurityManager(new
RMISecurityManager());
}
try {
String name = "//" + args[0]
+ "/HelloServer";
obj = (Hello) Naming.lookup(name);
message = obj.sayHello();
System.out.println("The message
is: " + message);
}
catch (Exception e) {
System.out.println("HelloClient
exception: " +
e.getMessage());
e.printStackTrace();
}
} // end main ()
}
/* Here is the java.policy file, no restrictions */
grant {
// Allow everything for now
permission java.security.AllPermission;
};
/* Here is the javaNetwork.policy file, with restriction */
grant {
permission java.net.SocketPermission
"*:1024-65535",
"connect,accept";
permission java.net.SocketPermission
"*:80", "connect";
};
/* Here is the javaLocal.policy
file, with restrictions */
grant {
permission java.net.SocketPermission
"*:1024-65535",
"connect,accept";
permission java.io.FilePermission
"c:\\public_html\\helloClient\\-",
"read";
permission java.io.FilePermission
"c:\\public_html\\helloServer\\-",
"read";
};
PREPARATION STEP: After compiling the *.class and stub and skeleton files (these are in the package simple.hello so you have to take this into account when running rmic and javac and java) I moved the files to the following directories on my local host and my remote host. It is only necessary to have both the client and server files on the same computer if you are going to have that computer do both jobs, otherwise only locate the appropriate files.
The Client Stuff:
C:\public_html\helloClient\java.policy
C:\public_html\helloClient\javaLocal.policy
C:\public_html\helloClient\javaNetwork.policy
C:\public_html\helloClient\simple\hello\Hello.class
C:\public_html\helloClient\ simple \hello\HelloClient.class
C:\public_html\helloClient\ simple \hello\HelloImpl_Stub.class
The Server Stuff:
C:\public_html\helloServer\java.policy
C:\public_html\helloServer\javaLocal.policy
C:\public_html\helloServer\javaNetwork.policy
C:\public_html\helloServer\ simple \hello\Hello.class
C:\public_html\helloServer\ simple \hello\HelloImpl.class
C:\public_html\helloServer\ simple \hello\HelloImpl_Skel.class
C:\public_html\helloServer\ simple \hello\HelloImpl_Stub.class
The Web File Server files to be located on the Server computer for a Two Computer Network.
C:\public_html\fileserver\examples\classServer\ClassFileServer.class
C:\public_html\fileserver\examples\classServer\ClassServer.class
In the following procedures, I describe the steps for two different setups. The first is an example of running both the server and client from the same computer without having to use a Web file server. The second is an example of running the client on one computer and running the server on another computer connected via network. This requires that a Web file server be running on the computer acting as the server. Sun JavaSoft has a simple Web file server class (ClassFileServer) that you can download for this purpose available at: ftp://java.sun.com/pub/jdk1.1/rmi/class-server.zip. The following procedures are for a Win32 PC as I do not have access to a UNIX system. see
PROCEDURE FOR RUNNING BOTH SERVER AND CLIENT ON THE SAME COMPUTER USING FILES WITHOUT REQUIRING WEB FILE SERVER. My computer hostname is john_i.
Step 1 - Clear the CLASSPATH variable and start the RMI registry on the Server: Do the following commands in a MSDOS Command prompt window:
set CLASSPATH=
start rmiregistry
Step 2 - Set the CLASSPATH and start the Server: Do the following commands in a MSDOS Command prompt window:
c:
cd \public_html\helloServer
set CLASSPATH=.;C:\public_html\helloServer
start java -Djava.rmi.server.codebase=file:/c:\public_html\helloServer/
-Djava.rmi.server.hostname=john_i
-Djava.security.policy=javaLocal.policy simple.hello.HelloImpl
Step 3 - Set the CLASSPATH and start the Client: Do the following commands in a MSDOS Command prompt window:
cd \public_html\helloClient
set CLASSPATH=.;C:\public_html\helloClient
java -Djava.rmi.server.codebase=file:/c:\public_html\helloClient/
-Djava.security.policy=javaLocal.policy simple.hello.HelloClient
john_i
You should see the Console output: "The message
is: Hello World!"
PROCEDURE FOR RUNNING SERVER AND CLIENT ON THE DIFFERENT NETWORK CONNECTED COMPUTERS WHICH REQUIRES WEB FILE SERVER. My client is called "john_i" and my server is called "homer".
Step 1 - Start the Web file server on the server (homer) computer: Do the following commands in a MSDOS Command prompt window:
c:
cd \public_html\fileserver
start java examples.classServer.ClassFileServer 2001
/public_html/helloServer
Here, the port 2001 is used by the web file server and
the classpath where the web file server locates the class files is /public_html/helloServer
NOTE: This presumes that network port 2001 is available on the server computer.
Step 2 - Clear the CLASSPATH variable and start the RMI registry on the Server: Do the following commands in a MSDOS Command prompt window:
set CLASSPATH=
start rmiregistry
Step 3 - Set the CLASSPATH and start the Server: Do the following commands in a MSDOS Command prompt window:
c:
cd ..\public_html\helloServer
set CLASSPATH=.;C:\public_html\helloServer
start java -Djava.rmi.server.codebase=http://homer:2001/
-Djava.rmi.server.hostname=homer
-Djava.security.policy=javaNetwork.policy simple.hello.HelloImpl
Here the codebase parameter defines what the web file server URL location of the classes being provided by the hello server are located. Since the ClassFileServer was setup with its class path setting already configured for /public_html/helloServer it is only necessary to specify the URL for the web file server. Specifying java.rmi.server.codebase=http://homer:2001/public_html/helloServer for the codebase will lead to a remoteException error because this will, in effect, result in the HelloServer looking for class files in a nonexistent path http://homer:2001/public_html/helloServer/public_html/helloServer/simple/hello/.
Step 4 - On the client (john_i) computer, set the CLASSPATH and start the Client: Do the following commands in a MSDOS Command prompt window:
c:
cd \public_html\helloClient
set CLASSPATH=.;C:\public_html\helloClient
java -Djava.rmi.server.codebase=file:/c:\public_html\helloClient/
-Djava.security.policy=javaNetwork.policy simple.hello.HelloClient
homer
Again, you should see the console output: "The
message is: Hello World!"
31 July, 1999 Using Vector to hold Multiple Object Types
1. The following code illustrates how it is possible to use the Vector class to contain different Class objects. The trick is to have a common base class that allows identification of the derived class type for recasting when extracting the Vector's elements.
class BaseType
{
public static final int BASEID
= 1;
protected int typeID;
public static int getBaseTypeID
() {return BASEID;}
public int getTypeID() {return
typeID;}
}
class Type1 extends BaseType
{
public static final int TYPEID1
= 2;
protected float valueF;
public Type1(float value)
{
typeID = TYPEID1;
valueF=value;
}
public static int getType1ID()
{return TYPEID1;}
public float getValue ()
{
return valueF;
}
} // end Type1
class Type2 extends BaseType
{
public static final int TYPEID2
= 3;
protected String[] theStrings;
public Type2(String[] strings)
{
int i;
typeID = TYPEID2;
theStrings = new String[strings.length];
for (i=0; i<strings.length;i++)
{
theStrings[i] = new String(strings[i]);
}
}
public static int getType2ID()
{return TYPEID2;}
public String[] getStrings()
{
int i;
String[] strings = new String[theStrings.length];
for (i=0; i<theStrings.length;i++)
{
strings[i] = new String(theStrings[i]);
}
return strings;
}
}// End Type2
public void doit ()
{
int i;
BaseType base;
Type1 type1;
Type2 type2;
Vector v = new Vector();
String[] s1 = {"FOO1", "FOO2"};
String[] s2 = {"HOSER1","HOSER2","HOSER3"};
v.addElement(new Type2(s2));
v.addElement(new Type1(3.45f));
v.addElement(new Type2(s1));
v.addElement(new Type1(5.69f));
Enumeration e = v.elements();
while (e.hasMoreElements())
{
base = (BaseType) e.nextElement();
switch (base.getTypeID())
{
case Type1.TYPEID1:
type1 = (Type1) base;
System.out.println ("Type 1
value = " + type1.getValue());
break;
case Type2.TYPEID2:
type2 = (Type2) base;
String[] results = type2.getStrings();
for (i=0;i<results.length;i++)
{
System.out.println("Type 2 String
" + i + ": " + results[i]);
}
break;
}
}
13 August 1999, RMI LAB 4 - Daily Programming Notes.
1. Troubles with Borland JBuilder 3 vs. the command line program start.
While continuing to work on my Lab 4 Ship Tracks RMI client/server applications, I started to use JBuilder 3. After some fiddling around with the configuration settings, relocating the project files, and using the JBuilder menu command to start the RMI registry I was able to actually start the server and the client from within JBuilder itself. But, when I went to try to run the JBuilder compiled output from the MSDOS command prompt outside of JBuilder, the server would not start because of a Class not found exception on not finding the shipTracks.TrackServerImpl_Stub. I verified that CLASSPATH and my -Djava.rmi.server.codebase= parameter had the correct path settings to get to the base directory for the class files. Finally, I went back and manually used the RMIC program from the command line to recreate the stubs and skeletons. Once I did this, the server was able to start up from the command line. Evidently, JBuilder's RMIC call must create the stubs customized such they only run from the JBuilder IDE. I also noted that if I started the rmiregistry from the command line, the track server application could not start up from within JBuilder. Evidently, you cannot mix and match between command line invocations and the JBuilder run command.
15 August 1999, RMI LAB4 - Daily Programming Notes
1. Internal errors in client propagated back to the server via the RemoteException. I found that an internal programming error on my client was getting back to the server via the remote exception. It had nothing to do with the network connection. The lesson here is that you need to catch any errors your client may throw in your remote interface if you don't want the server to be affected by something going wrong in the client. On the other hand, if you may want the server to do something if a client does go bad.
19 August 1999, RMI LAB 4 - Dailey Programming Notes - The Final Stretch
1. Unable to use jar files on remote machine. I found that it was impossible to use the trackServer.jar file directly on the remote (server) machine because the simple fileserver application I downloaded from Sun Java does not support retrieving class files from jar files. It can only retrieve *.class files. I am unable to access any of the ECT servers due to an change in the school's database which failed to list me as an ECT graduate student taking a course. Because of this, I cannot try to run from any of the Chico servers. Another problem is that I need the JDK 1.2.2 Java2D API and I don't know if any of the Chico ECT servers has the JRE 1.2.2 loaded up. The campus-unix is an HPUX with JRE 1.1.3.
2. A reminder on rmic stubs and skeleton class files.
The server side must have both the stub and the skeleton class file for
its RMI interface implementation class. The client side only has to have
the stub class file.