/*
 * testLoadingRemoteClasses.java
 */

package harbor.test;
import harbor.interfaces.*;
import kewlstuff.harbor.client.*;

/**
 *
 * @author Johnny Kewl
 * TEST 2
 * This test LOADS a class AT the REMOTE harbor and runs it THERE
 */
public class testLoadingRemoteClasses {
    private Vessel vessel = null;    
    
    /** Creates a new instance of testLoadingRemoteClasses */
    public testLoadingRemoteClasses() {
        String harborUrl = "http://localhost:8080/harbor/service"; //location of container harbor
        vessel = new Vessel(harborUrl); //get a vessel from the harbor
    }
    
    public void runTest(){
        I_MsgTest i_MsgTest = (I_MsgTest)vessel.loadRemoteClassInst(I_MsgTest.class,"harbor.classContainer.MsgTest");//load a class instance ON the harbor        
        if(i_MsgTest != null){// if class is null check the url and make sure tomcat is running
            System.out.print("This produced by remote service " + i_MsgTest.getTheMsg() + "\n");
            
            String s = "I am a test string placed on remote service by local call";
            i_MsgTest.setString(s);
            System.out.print("Test String " + i_MsgTest.getString() + "\n");
            
            //NB NB NB Clean up explictly
            //Notice how the class is identified using i_MsgTest.toString()
            //It gives you the URL called and the unique client identifier
            if(vessel.releaseRemoteClassInst(i_MsgTest)) System.out.print("Instance on remote harbor, is released " + i_MsgTest.toString() + "\n");
        }

    }
}
/* Notes:
 * LOADS... means even though we control the classes on the client, and it feels like
 * they running here... they actually running on a server on the other side of the planet.
 *
 * Very simple code to write and incredible when you think that MsgTest is not running
 * on this machine.
 * Writing a remote service, is as simple as writing a java class library.
 *
 * Only thing to remember here is that the remote machine does not know when to release
 * the class we loaded. Make sure you release the class when you done.
 * 
 * The software is smart, it will clean up the remote service through normal garbage collection
 * BUT... the problem is that the client machine may have tons of memory available
 * and garbage collection could take a long time, meanwhile the remote classes are using
 * valuable memory on a struggling remote machine with 100000 clients accessing it.
 *
 * The other reason for explicitly cleaning up is that the client, this machine, may be
 * on a dial up, so you want to clean up before the user has a chance to disconnect.
 * If you leave it to garbage collection, it may only try clean up in 20 minutes time,
 * and if the connection is gone, the remote classes are stranded in memory.
 *
 * As of REV 3... the harbor server has a ADMIN SERVLET (/harbor/admin) built into it.
 * The (Release Remote Class Instances) option allows the super_admin user to keep
 * track of mis-behaving clients. So if you forget to clean up, you will see which client
 * is being naughty and be able to determine the location.
 */