/*
 * testSerializingObjects.java
 */

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


/*
 * @author Johnny Kewl
 * TEST 4
 * This INJECTs a serializable object into another object.
 */
public class testSerializingObjects {
      private Vessel vessel = null;
    
    /** Creates a new instance of testSerializingObjects */
    public testSerializingObjects() {
        String harborUrl = "http://localhost:8080/harbor/service"; //location of container harbor
        vessel = new Vessel(harborUrl); //get a vessel from the harbor 
        
        //This is just a debugging tool... 
        vessel.verboseVessel(true);// watch the local class loading process in system.out, for debugging 
    }
    public void runTest(){
        //Error checking ommitted so one can follow code easily
        
        //Get a remote class and make instance... it runs on local machine... add a message to it
        Class c_serialObject = vessel.getRemoteClass("harbor.classContainer.serialObject");
        I_serialObject i_serialObject = (I_serialObject)vessel.newInst(c_serialObject);
        i_serialObject.addMessageToBox("My first message to class on local machine");
        
        //load class on remote machine
        I_serialContainer i_serialContainer = (I_serialContainer)vessel.loadRemoteClassInst(I_serialContainer.class,"harbor.classContainer.serialContainer");//load a class instance ON the harbor
        
        //put local serialObject into remote container... the local object has to stream down to container
        i_serialContainer.setBoxOfMessages(i_serialObject);

        //add another message to the classes running at the harbor
        i_serialContainer.addMessageToBox("My second message added to messagebox in remote container");       
        
        //get the new serialObject on remote container... the remote object has to stream up to us
        I_serialObject i_serialObjectNew = i_serialContainer.getBoxOfMessages(); 
        
        //display the messages... class running on local machine
        System.out.print("Msg1 " + i_serialObjectNew.getMessageFromBox(0) + "\n");
        System.out.print("Msg2 " + i_serialObjectNew.getMessageFromBox(1) + "\n");
        
        vessel.releaseRemoteClassInst(i_serialContainer);
        

   }     
}

/* Notes:
 *
 * To the uninitiated, these tests may almost seem silly, such simple pieces of
 * code... whats the point?
 * These tests are actually about making the simple DESIGN PATTERNS that we
 * use in Java... work! But hang on, this is java, so again whats the point?
 * Yes, it is, but it only works as normal java, because of the wizardry of Harbor.
 * Normal Java cant have one class running 2000 kms away from another class, and
 * then use that class in a client object, that is not actually running on the
 * client, but rather on the server.
 *
 * When one puts distances into it, it suddenly becomes all too clear that there is
 * some magic happening.
 * A class is pulled off a server (2000km away) started and actually runs on the
 * client.
 * Another class is started on a server (2000km away) and it feels like its running
 * on the client, but its actually running at the server.
 * Then we inject the local class, into what feels like a local method, and it
 * actually runs in that method (2000km away), on the server.
 * And then just to show off, we reverse the process, and bring it back.
 *
 * Suddenly that code doesnt seem so simple anymore... but that doesnt really matter
 * because it feels like normal POJO (Plain Old Java) and thats nice because
 * its easy to use, its how we think.
 *
 * A POJO container, is really about making normal simple java design patterns work
 * across the wire, in the easiest way possible. 
 * Theres a natural specification at work, its the Java language itself. 
 *
 * On the server side, its just normal unaltered java code, on the client side
 * NEW Class is replaced with a few distance aware functions in a tiny API.
 *
 * Simple Java on top, a serious invisible engine underneath... thats a POJO container.
 *
 * Even the environment is is deceptively simple... you drop the POJO container
 * into Tomcat... then drop your JARs into that... done!
 * The technology works in the universal WEB environment, on the web protocol, in
 * fact if you look at it carefully, the Pojo Container is actually a web site and
 * that means the technology addendums are endless. 
 * For example if you need to change the deployed JARS, FTP or WebDav will work
 * just fine. If a remote client, via a class writes an output help file to a
 * folder, well yes, that instantly becomes a web page.
 * The Admin tools are mostly instrumentation, a gentle reminder of the mean
 * machine running underneath the POJO, but theres hardly anything to do because
 * it pure Java at work.
 *
 * Some technical points on the example...
 * Keep in mind that when one serializes a class to the server, the server must
 * be able to find that class. So there is a little trick at work here, that is
 * if we GET a class from a server, we immediately know it can be serialized back
 * to that server. If you look at the Harbor_Test_Lib code, you will see the
 * class carries a serializable interface, that is necessary whenever a class
 * moves over the wire.
 *
 * Dont get confused here... if you look at the testControllingRemoteObjects
 * test pattern... you will see those classes dont have a serializable interface.
 * Remember that when you LOAD a class, it feels like its running on the client
 * but its actually running on the server. In that example the classes are both
 * running in the server, and even though they feel like they on the client,
 * they have never left the server, and thus INJECTION of one into the other
 * does not need a serializable interface because they actually right next to
 * each other in the same server.
 *
 * Make sure you understand when a class gets serialized and when it doesnt.
 */