/*
 * testAdvancedClassRepositoryControl.java
 */

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

/**
 * TEST 5
 * Changes the remote server classloader
 * To see this working... set the log_level on the server to 2 (web.xml)
 * Then open /harbor/admin and view the log files after this client run.
 */
public class testAdvancedClassRepositoryControl {
    private Vessel vessel = null;
    private ClassLoader vcl = null;
    private RemoteClassLoader rcl = null;
    
    /** Creates a new instance of testAdvancedControl */
    public testAdvancedClassRepositoryControl() {
        String harborUrl = "http://localhost:8080/harbor/service"; //location of container harbor
        vessel = new Vessel(harborUrl); //get a vessel from the harbor  
        rcl  = (RemoteClassLoader)vessel.getVesselClassLoader();
        
        
    }
    
    public void runTest(){
        
        //Remote server classes will load up
        I_MsgTest i_MsgTest = (I_MsgTest)vessel.loadRemoteClassInst(I_MsgTest.class,"harbor.classContainer.MsgTest");//load a class instance ON the harbor 
        vessel.releaseRemoteClassInst(i_MsgTest);
        
        //Remote server classes will NOT reload it knows its got them already
        i_MsgTest = (I_MsgTest)vessel.loadRemoteClassInst(I_MsgTest.class,"harbor.classContainer.MsgTest");//load a class instance ON the harbor 
        vessel.releaseRemoteClassInst(i_MsgTest);
        
        //Tell Server to make a new classLoader          
        rcl.newHarborClassLoader(true);
        
        //rcl.reloadClassRoles(); //see notes
        
        //Remote server classes will AGAIN load up fresh copies of classes
        i_MsgTest = (I_MsgTest)vessel.loadRemoteClassInst(I_MsgTest.class,"harbor.classContainer.MsgTest");//load a class instance ON the harbor 
        vessel.releaseRemoteClassInst(i_MsgTest);        
    }
    
}

/* Notes:
 *
 * NEW CLASS LOADER - newHarborClassLoader
 *
 * Ok, why do this?
 * The remote HARBOR is smart, it will load up the classes in your class REPOSITORY
 *
 * .... which incidently you can set in WEB.XML eg
         <init-param>
          <param-name>harbor_location</param-name>
          <param-value>HarborRepository</param-value>
        </init-param>
 * .... This folder is located under your WebApp.
 * 
 * and if those classes are used again, they are not reloaded, because the system
 * knows they are already available in the cache.
 * BUT this creates a little problem, because say you change some code and add the new
 * classes to the REPOSITORY... they will not load up if they have already been used,
 * because there is a copy of the class sitting in memory already.
 * So, you fix a bug and want the remote clients to use the new class, but they
 * will continue using the old class. When you testing, you can just stop and
 * start Tomcat, but in a production environment you cant do that.
 *
 * So what you do is call (newHarborClassLoader) and the system will then reload the
 * classes from the HARBOR REPOSITORY when the next client asks for them.
 *
 * The existing clients continue to use the old classes, and the old classes will
 * be cleaned up when all the clients are finished.
 *
 * The most important thing to remember is that (loadRemoteClassInst) clients must
 * (releaseRemoteClassInst)
 * because if they dont do that, the old class loader will never die...
 *
 * You can use the Admin Console at /harbor/admin to monitor classes that have
 * not been released.
 * If you have clients that dont release, you can use the Admin Console
 * to see which ones are misbehaving, and remove them, its a nice way to catch those
 * little whoopsies.
 *
 * Note that this discussion does not apply to singletons.
 * By definition a singleton is a class that is not released, so you will expect
 * to see those in the /harbor/admin Remote Object Cache utility.
 * If you release a singleton it will automatically release its dedicated classloader. 
 *
 * CLASS SECURITY - reloadClassRoles
 *
 * This is another handy function related to class security.
 * Should you require class security have a look at the Access example
 * and read the notes in the class_guard.xml file under WEB-INF.
 *
 * (reloadClassRoles) simply reloads your class security file so you
 * can change the classes you want protected without having to restart
 * tomcat.
 *
 * These functions have no direct client effect... if you want to monitor the effect
 * of the above test, set the Web.xml Log Level to 2... you will be able to see
 * the class loading behaviour in the mass of log messages created.
 * 
 * Everything you see here can be done via the /harbor/admin console, and everything
 * you see in the /harbor/admin console can also be done programmatically like this example.
 * If you new to this, dont worry about it too much, just use the Admin Console, however 
 * if later you need to automate any of that functionlity... its as easy as this example.
 *
 * You will notice that if say your application repository is called HarborRepository,
 * when you start running applications, that another folder is created and in this case
 * it will be called _HarborRepository. If you look at this folder you will
 * see duplicates of the classes and Jars you using. Do not touch this hidden folder,
 * because these are the actual classes running. 
 * The reason you can drop classes and Jars into you repository at any time, is
 * because harbor doesnt make them go live until they are needed and then it
 * keeps the live ones away from the ones you want to change.
 * You will see that the hidden folder classes come and go.
 */