Harbor has not started yet, even though you start Tomcat, Harbor will not actually start until it gets some work to do.

This is so it doesn't break your browser, it will roll over at 500kb, however if you look at the top of the log file it will tell you the file name of the previous log file, if you type that in the browser you can track through all your log files.

You MUST run your production server on Log Level 0.
That will tell you if there are any problems, the other Log Levels are really only for developers, and internally do all sorts of other fancy things, like beep when a class loader releases, force garbage collection and other things to help a developer see how their application is behaving. BUT its slows down the server a great deal.

It will eventually fall back, and that is true, on a system with a lot of memory you may see your applications duplicated up to as much as 1000 times.
This is because Harbor is allowing you to change applications, even while clients are "in" the old ones. When the old clients finally release their classes, this releases internal class loaders, however only when the JRE (Java itself) decides to do garbage collection, will these folders suddenly fall back. There is no way of knowing when the JRE will do it, other than it happens quicker if the system is busy.

Its really not an indication of anything good or bad, other than the amazing ability to change running applications. Namely drop new applications in, and then from the admin console Start a New Class Loader.

The real test is to look at Current Class Instances that is an indication of trouble brewing.
If you see classes growing rapidly in there, it means you have a Ship out there that is not releasing. You need to recall it and fix the coding error.
You are able to see the IP of the misbehaving ship.
Harbor has a safety feature as well, if any one IP address tries to create more than 500 instances of a primary class, you will see a CRAZY SHIP log message, and Harbor will ignore any more requests from that Ship.

If you take Tomcat down, you can delete the _HarborRepository before bringing it back up, but never touch these files while the system is running.

Usually nothing more than an application that has not been debugged properly, and it gets itself into a loop, or simply doesn't releases classes.

If you want to get a feel for what happens, the UI sample application has been designed not to release while the UI is open, so if you start a few of those, you will see how instances grow and when you close the UI, you will see them disappear again.

Crazy Ships or misbehaving CD Units are bad news, because remember they are out there, and if you cant recall them, it effectively means you have to remove that application and sink those ships.
If its just coming from one IP, there is probably someone out there that doesn't like you. You can either use a tomcat valve to block the IP (not recommended), or set your incoming router or firewall to block that IP from the whole organization. If you sure its not your application, then you should also try trace them and press charges, effectively they are running a flood attack.

Remember that you do have control of the entire application, and it may not in fact be the CD Unit that is misbehaving, it could be the UI side, in which case, simply fix it, drop it back in and start a new class loader.
If it is the CD Unit, and you delivering via the web, you can change it and hope that people are using their browser to start applications, i.e. they are pulling down the CD Unit. If not and 100,000 people have it stored and are say launching it from disk, or a previous download, you are screwed... and your application has to be removed. 

Test carefully, and in the development environment when using Log_Level 1 or 2, Harbor does things like beep when a class loader is shutting down, and force garbage collection so they will shut down immediately, so that while you are developing, not only can you see it in the log messages, you can hear it working.

There is another cache folder called _Shipping created. If your application is called MAGIC.JAR, you will see under this cache folder that its called MAGIC.ZIP

After you replace your old ship, with the new code, you need to delete the cache file as well. Harbor repacks your files so that they can be delivered via the browser, and for efficiency reasons, it only packs it the first time it called, thereafter clients get the cached version.

* Note *

In the SHIP (CD Unit) you will see the lines

String harborUrl = "http://localhost:8080/harbor/service";
vessel = new Vessel(harborUrl);

This is telling the software where your server is, and it points at the default URL on Tomcat. When you put Tomcat online, you need to point the URL at the new URL. It will be something like...

String harborUrl = "http://www.YourCo.Com/harbor/service";
vessel = new Vessel(harborUrl);

• Then you will compile the Ship (just the ship), and place the Dist files under the Ships/Your App Folder.
• And because you probably tried it already, delete the _Shipping folder under webapps/harbor (i.e. the above comments apply).

If you have it wrong, you will see it download the CD_Unit (Ship) in the browser, then it will pop up the progress dialog and do nothing because the Ship is trying to get the application from the wrong server.

If a remote application starts a singleton class, only it can release it, its IP address dependent. From the Admin console you have to Super_Admin_Logon first.
If you trying that and its not working, it likely that you need to place

<user username="super_admin" password="" roles="super_admin"/> 

in your Tomcat\conf\tomcat-users.xml file.

Then Logon with  super_admin no password, and then Release Remote Class will work.

If you want to get into Servlet programming or learn more about how to control Tomcat, for example stick it on port 80....

Join the mailing lists http://tomcat.apache.org/lists.html

Even though as you have probably guessed we not terribly fond of the J2EE EJB specification, we do think the best thing that ever came out of Sun, besides the wonderful java language is the J2EE SERVLET specification, and Tomcat is nothing short of amazing.

There is absolutely nothing that you will not be able to do, with Tomcat, Apache and Harbor.

You may be surprised to hear that Harbor does not impose ANY interfaces on your code.

If you having problems understanding INTERFACES, then the best reference is the SUN TUT at http://java.sun.com/docs/books/tutorial/

But this may help you a little, when you use a class in a program, that is neither in the IMPORT and that you do not NEW anywhere, how do you do it?

When it is injected into the program, you need a way to use it... BUT your class doesn't know what it is yet? See the problem? That's what interfaces are used for, and they even allow you to change the versions of the object that will be injected.

In other words you cant write...

MyClass myClass because you haven't got the class.
So the thing wont even compile.... 

So you simply define an interface...

I_MyClass i_myclass = *whatever* and then any class you want to inject and use, must simply carry that interface.

Hope that gets you going..... they used whenever you want to pass an object into another class, and that class doesn't know exactly what the object will be, nor can it import it or initialize it.

If you want to write great code, you need to know how to decouple classes, and interfaces are the way to do it. Sometimes its just called late binding.

You don't... for simple little programs that you just want to run client side.

BUT... where your program has a definite server side and definite client side, you must decouple those sides.

For example if your client side uses a database object that must stay on the server, you have to decouple it... i.e. the client side must use an INTERFACE to that database object.

Can you see why.... besides just being a terrific programmer?

If in the client you use the class directly in the IMPORT, or you NEW it, can you see that when the client loads up on the other side of the planet, that it will take that class with it.
A class loader is a very smart thing, if it sees that you need that class, it will get it as well, so then you have EVERYTHING sitting at your customer.

Now if you have used an interface to the dB pool, the actual dB pool will not go with the client, when it is loaded up at the customer, and thus you can inject what you want, when you want, into the client, through the CD_Unit.

So, one way to look at it is that you need to use interfaces for any server side classes you want to use in your client, the other way to think of it is that it is also very good MVC model programming... can you see why?
Simply because, if you ever decided to inject DATABASE 2 instead of DATABASE 1.... nothing in your code changes, that's the big WadaWada about the MVC model.

Learn interfaces, you cant write good code without them, even outside of Harbor.

The honest answer is no, even though that is the ultimate goal.
When designing an application, its a good idea to try keep the structures that move over the wire fairly simple, and as for the rest of it, Harbor will run (just about) everything. In other words right now we don't know of something it doesn't run.

If you do discover a structure that Harbor does not handle, we would appreciate it if you isolated that structure in the form of a test, and send it to us, we will fix it.

Two of the examples that come with Harbor, namely the Mailing Engine, and the dB Demo, both use sophisticated and complex libraries, namely Java Mail and Derby. Its a good measure of just how sophisticated the internal engine is, and short of writing code that is more elaborate than what's in those libraries, not many people can, you should be just fine.

Harbor is a machine with the amazing ability to take what you develop standalone and put it on the wire. It is deceptively simple, and a good way to appreciate what is going on behind the scenes, is to wind up the Log Level to 2 (web.xml file), start Tomcat in a terminal window (from the bat file), and then watch as Harbor delivers the application.
If you run something like the dB Demo, take a tranquilizer first, the classes being manipulated will stream past your Dos window.
Incidentally its a great way to spy on the libraries you use, for example with the dB demo, you will see exactly what the Derby library gets up to. If it happens too fast, just open the log file from the admin console, at Log Level 2 it will all be in there as well.
If you add the vessel.Verbose(true) option to your CD unit, (as we have done in the tests), you will see the classes coming down to the CD unit (i.e. on the client side) as well.

So yes, if one try's hard enough, it is possible to create an application that doesn't work on Harbor, but conversely, one should have no problems making one that does work.

This is a modest appraisal, don't let it put you off, Harbor goes way beyond beans, but we have to be modest because we get asked incredulous questions, like can one take Tomcat, put it in Harbor, with Harbor and deliver Harbor with Tomcat to remote machines... we don't think so. 

Yes... Harbor is in a class of its own. 
We have not made any comparisons to legacy application servers, they simply cant do what Harbor does.

More interesting and what may really surprise you is that we think Harbor is quite capable of changing the face of the Web, that's where this is going.
We think that in many cases its going to be better for an organization to deliver Java, than hypertext, or at least powerful mix of both.

Harbor is highly efficient. 
On both the client side and server side, Harbor runs as fast as your standalone application... what you create, is what Harbor does. 
The interesting aspect is the application delivery, we'll leave you with some figures, and you can decide for yourself.

When you run the dB example, this is what happens...

• If you running it for the very first time, it takes a little while, but that has nothing to do with delivery, its because the embedded dB is slow and takes a long time to set up a data pool, that only happens once on first start  up, and would not happen if you ran against a powerful external dB, like Postgresql.
• If the dB example is the first Harbor UI application to run on the client's machine, the Control Panel download will be approx 54 kb
• When the user clicks on the Entry Form, that UI will download and open, the download is approx 14 kb
• When the user clicks on the View Form, that UI will download and open, the download is approx 8 kb
• If the user then starts working and opens and closes forms, the download is (zero) 0 kb besides the small data transactions.
• Now if the user closes the application and restarts it, or starts any other application with similar dependencies, this time the download will be approx 6kb when the application starts.
• 4 kb when the Entry Form is again opened.
• 7 kb when the View Form is again opened.

Clearly the Harbor client learns.
The application is stock standard and no attempt has been made to optimize it, it uses the heavy fancy Swing libraries.
Using the light AWT components would improve on that even more.
Nevertheless, as you can see, the application as is, is already very Internet friendly.

This is related to the above question, and its about Harbor Client efficiency, across applications.
The way to use it, is simple, put all classes and libraries in there that don't change often. 
The more sophisticated answer is that it puts these libraries into the Client side persisted class path.
So for example in the UI examples we use the swing-layout-1.0.jar file, its a Sun/Netbeans library that makes designing UI layouts easy.

We never going to change it, and its used by all programs, so we make it Ever-Lasting on the client. That library will persist between different applications and that means it is not uploaded to the user in every application.

Note that should you decide to change it, you can, and the new libraries will be used, however understand that the client side library will be replaced with the new one. In most cases that's not a problem, but if the client is extremely active, for example its a component in a remote busy servlet cluster, remember that if it suddenly changes, it may confuse the other 150 clients using it.

So the rule is, put libraries into this that do not change often, that translates to system libraries that you use, and your own steady libraries.

Note also that you should not and do not have to duplicate libraries, the server side will also see and use those libraries as normal libraries, if needed.

On a LAN we don't bother with this, its so fast already it seems to hardly make any difference, but when your clients are out there on the internet, its important, because it makes Harbor very efficient. Naturally it also reduces server load.

If you look at the CD Unit (Ship) code in the dB example you will see the line

vessel.enableProgressDisplay(true); //for internet apps

If you remove the line, the progress dialog will not appear.

When one writes their application if there are long downloads, perhaps its a video editor or something with large data assemblies, you must create your own progress indicators.

This progress indicator is for the part you cant control. If the application itself is taking a long time to load on the internet, this progress indicator will become active.
If the download takes longer than 2 seconds, it pops up and shows the user the classes coming down to the machine. If you testing on a LAN, it may only just flick open and closed for a second or two... you need to be on a slow connection to see it work.
If it irritates the user and they click HIDE, it stays off.

For some reason this seems to be confusing users.

What we mean by Stand-Alone is the application running by itself without the container.
All the examples DO NOT NEED THE CONTAINER, to run. 

So if for example you took that game code, stuck it into your development environment, forget about the container, just take that example code and compile it, you will see it runs, on its own.
It cant run on the network or on the Internet, but it runs happily as a Java application on your PC.

You do not develop, or test your code in the container... see how easy that is?

We think its confusing people because EJB has a concept of LOCAL and REMOTE interface.... i.e. when the application runs on the wire, and when it runs local on the machine.

Harbor has no concept of LOCAL interface.
Local to Harbor, just means the application runs on its own, without the container, it runs Stand-Alone.

1. Forget about the container, pretend its not there.
2. Make a Stand-Alone application, debug it and test it.
3. Check that the application is all controlled from one class called the CD Unit, using normal POJO.
4. Now start thinking about the container, drop the application and its libraries into the repository of Harbor.
5. Make another SHIP Java project, start by copying the original POJO CD unit.
6. Decide what you want to run on the client, and what you want to run on the server. Replace the instantiation of the classes with the Harbor API as required (see the examples).
7. Start Tomcat, and run your Ship from the IDE, the application should start, if not, debug as required.
8. When the Ship is debugged, drop it into the Ships folder (See Ships article).
9. Type the URL into the browser and see if it works.

This is covered in detail here.

The default in Harbor is human protection, which means if communications are insecure, or the server has not identified itself, the user is warned.

Note that one is not forced to go secure, the user is warned, and has a choice.

However all these dialogs get in the way when the user is not human, like when its another server using libraries or services in a Harbor server.
In this case one can invoke this call.

vessel.setHeadless(true); //machine usage

This will remove all those human security dialogs, and if a problem occurs, like the certificate fails, or the server fails the challenge, a SSL80Exception is thrown.

If you use this option the user gets absolutely no help, and if something fails, they will not know why, however when incorporating remote Harbor services into a servlet container one may prefer exceptions to UI messages, because the system is unmanned.

This is how Harbor lets one easily design for human or machine.

As of version 1.0.2, we added a user configuration file.
The best way to see how it may be used is to look at the ATM Demo Ship.

At <user folder location>/harbor/user

if one adds a property file called config.txt

then those properties can be read on the client side, thus giving one a convenient way to allow a user to change default configurations.

All the Demo's, now incorporate the property (See Finding Myself)

HARBOR_SITE_URL = http://yourMachineName:8080/harbor/service

This means that without recompiling the demos, one can simply add this property to other machines, then because the Ships can now locate the test server in your company, those demo's will run on other machines as well.

As of version 1.0.7 Harbor has a very useful property that is AUTO set for you.
It is now no longer necessary to set the HARBOR_SITE_URL property on the users machine for the sample code.

The samples are now doing this...

String harborUrl = null; //"http://localhost:8080/harbor/service"; 
Vessel.loadAppConfig(); //Set application to delivery server
harborUrl = Vessel.getAppProperty("HARBOR.SITE.CONTEXT");
vessel = new Vessel(harborUrl); //get a vessel from the harbor 

HARBOR.SITE.CONTEXT is the new property and it gets the URL of the machine that the application comes from.
Thus when one moves from localhost to a network domain, to an online system, there is no need to set special properties to locate the server.

Its read only, if you do set it in App.props then it will not auto set.

Because Harbor splits applications, it has two log facilities from the Ship.

vessel.setRemoteAdminLogMessage(0,"A Message To Admin");

will log this message in the Admin log on the server.

and

Vessel.setLocalAdminLogMessage("A Message to the User Log);

will place the message in <user folder location>/harbor/logs

on the clients machine.

Note that logs slow down and application and should be used sparingly.
Note also that the user log is a Static call.

Generally you will run your server as  high as possible, and your applications will be as low as possible.

Harbor runs on Java 5 and Java 6, so this translates to the server on Java 6 and client applications at Java 5.

Remember that when your application diffuses, the client side will be running on a remote machine and for maximum compatibility, the lower the application JRE, the better.

In practical terms it means you must make sure your applications target Java5.

The reason the server is on Java 6, is so that if one does target higher JRE clients, both Java 5 and Java 6 applications will work on the server.

Note that through coherent diffusion one can make Java 5 clients talk to Java 6 services on the server. It means that upgrading clients just to get at new features like scripting, may not be necessary anyway.

Tip: In an IDE like Netbeans, one can right click on the project and target the Java level. This works with careful design, but its still very easy to get caught.
The best way is to load up the Java 5 SDK on your machine, add it to the platform managers in NB, and then right click on the project and set libraries to platform Java 5. That way any inconsistencies will most definitely be seen while developing.

Typically if the clients try run on a JRE that doesnt support it, the user will get nasty looking exceptions. So one might want to check OS in their application.

On the server side, if the JRE is wrong, absolutely nothing happens, its dead.
One gets a vague message in the logs that the interface could not be loaded.

On Windows/Mac/Solaris it all works out of the box, this is because Harbor is based on Java Executables and when Java is installed these associations are done automatically across the entire system, including browsers. 

This is a "client side" conversation, on the server side, Linux is king, but the server also runs very well as a server on Windows XP (prof), we don't use big expensive MS servers just for intranets. For a small department with 100 people, its fine.

If the file association is not there, a user from the file manager, simply associates the JAR extension with Java Platform SE Binary, and its done.

But when it comes to file associations, Linux's technology unfortunately does not match its tenacious server ability. It seems most distributions still treat JARs as archives, or zip files and do not see JARs as programs that actually need to run. 
In addition, the myriad of desktops available all seem to behave independently and separate from browsers.

A very simple thing has to happen... namely a JAR is run with this command line.

java -jar <the filename.jar>

however without a little help from you, the magic of Harbor won't happen on Linux.

So, what has to happen is this...

• Make sure that if you type java -version in a terminal window that it works.
  If not put java in the system path... it should be there already if Java is installed.
• From which ever desktop you using, associate the
  JAR file type with
  java -jar (Java Runtime SE)
  In KDE Configure Desktop/KDE Components/File Associations will put you in the right place.
  On Debian with Gnome, one does it from the file manager, File/Properties/Open With

Linux is not integrated, so check that your Desktop, the File managers, and the Browser all know how to start a JAR file.

Although Firefox has a Tools -> Option ->Manage facility for managing file types, it seems unable to take parameters, i.e. placing the -jar into the command line seems impossible. You may get lucky and your distribution has fixed that, you may need to write a shell script and then associate with that.
The Opera browser is very good, does this and has good Java instructions. 

On systems like Windows, the Mac, and Solaris, the user does not have to do a thing, this all works as soon as Java is installed.

Unfortunately, there are no API in this area on Linux, it's not even possible for one to write a special program to do this for you. 
Its also unfortunate the distribution suppliers have chosen to make the default association point at an archive tool.
This means that if you don't change it, it will show you the insides of a Jar file.
Why they do this on Linux is very odd, and unfortunately Sun from the JRE seems unable to correct this on Linux. What this all means is that if the Linux user doesn't set it up, they miss out completely on the power of executable jars. 
We view the absence of the java executable on Linux as a very unfortunate over-site by distribution suppliers.

This also means that as the Harbor desktop evolves, one will see that it can integrate with the native desktop, i.e. the user can drop shortcuts down onto their native desktop, and make their Harbor ship behave just like a native application.

On Linux... this all has to be done by hand. What we are doing to reach out to Linux users, is developing the Harbor desktop a little further, so that one can start applications and files from the Harbor Desktop. To do this we tie into the browser on the system, so if the desktop will not start an associated file, the place to set it is in the browser. This is because on Linux one may have 3 file managers and 2 desktops running, all of which do their own file associations.

The Harbor desktop searches through browsers in this order..
firefox, opera, konqueror, epiphany, mozilla, netscape

and uses the first one in finds.
On other systems the file association is done centrally, and this does not apply.

We apologize on behalf of Desktop suppliers to Linux users, its just the way it is.

One can place Video and Media in the Harbor server.
Sun is not terrific in this area, and developers generally kludge this area.
To use our kludge...

import harbor.media.helper.MediaLauncher; //Library can be found in Harbor

MediaLauncher ml = new MediaLauncher();
ml.startMedia("http://yourUrl/on/Harbor/Server");

This function below is specific to MS box's only, we use it for playing sound on clients.

ml.startSound_MS("http://yourUrl/on/Harbor/Server");

This will play the sample that comes with Harbor, you need to put some music files on the Harbor server.

http://localhost:8080/harbor/ships/Media_Test_Ship.jar

Please note that it is System dependent and a little work around because Sun seems to have completely
forgotten about media in Java.

It allows one to play MP3's, Flash video's, Mpegs etc, but only if the default browser has that capability.
Its not pure Java. We use it to play training video's, on MS client box's, works well.

Its because of Java's current limitations in area's like this that we introduced the HAVA project. 

As of version 1.0.8

If one calls a ship like this for example...

http://localhost:8080/harbor/ships/Harbor_UIapp_Ship.jar?Param1=100&Param2=2020

then

Vessel.loadAppConfig();
String Param2_Value = Vessel.getAppProperty("Param2");

will get the value...

This means one can launch applications from a browser and supply query parameters.

Remember that they must be url encoded correctly...