Pre-Hansa

If you want the full background of the Hansa project in terms of codebases and design ideas, please go to the background page.

Overview

The Hansa system leverages the ability to extend the JVM with additional protocols. The JVM has 3 protocols built-in ( file:, http: and ftp: ), but allows for additional protocols to be installed. The Hansa system will leverage this ability to new and unexplored heights, effectively creating a very fluid URL based resource store, which can be used by any existing application that is already URL capable.

JVM Restrictions

There are a whole set of restrictions when adding protocols to the JVM, making the life for Hansa very difficult.

• It is possible to register a URLStreamHandlerFactory, but there can only be one in the entire JVM, and it must handle all protocols. Furthermore, if the protocol wants the URLs to work properly for the URLClassLoader, this factory can't be used. The fact that there can only be a single factory for the JVM makes this a no-no for a non-intrusive system as the Hansa is.

• It is possible to set a protocol handler package in the system properties (java.protocol.handlerpkgs), and if those handlers reside in the System Classloader, everything will work just neatly. The specification says that the protocol is located by taking the value of the above system property, add a package for the name of the requested protocol and if the class named Handler in that package extends the java.net.URLStreamHandler, the class is used for the protocol.

• The Handler class will be cached in the JVM subsystem, and never released. That means we can not upgrade the protocol handler without bringing the JVM down. And for true 24/7 programs that is not an option. We need to live with the fact that the Handler is a "write-once, never-update" class, and need to nail it down bug-free.

Core

The Hansa system will initially implement 4 protocols, artifact:, link:, mount: and scp:. The first 3 are new and somewhat virtual, whereas scp: is Secure Copy which should exist in the JVM, and plainly missing.

It is important to remember to stay focused. There are many things that Hansa is/does not;

• Hansa is not a runtime platform.
• Hansa is not a classloader management solution.
• Hansa is not an application container.
• Hansa does not promote any design patterns.
• Hansa is not intrusive.
• Hansa does not require the application to know about its existence.
• Hansa is not a single solution, but a set of tools to create solutions with, some available from OPS4J.
• Hansa is not difficult to understand.

Application Program Interface (API)

The API for any application is over the java.net.URLclass, and only Hansa-aware applications that want to manage some aspect of the Hansa operation needs to use the management APIs, which are exposed per protocol.

We have defined 6 protocols that should be implemented in the first generation of Hansa. Since it will not be possible to upgrade a running Hansa system with new protocols without a restart, it is important that we cover the bases initially, and perhaps we should add more protocols from the start. The Handlers for each protocol is written in such a way that they will fail gracefully if no delegate is available. Hence, we can define the protocols now, implement the delegates and upgrade running platforms later. Please discuss additional protocols on general@lists.ops4j.org.

Current Protocols are

• Artifact
• Pakkage
• Link
• Mount
• Scp
• Svn

Also see the Create A Protocol page for information on how to create a new protocol for Hansa.

Service Provider Interface (SPI)

The SPI defines the interfaces that are used in between the subsystem implementations. It allows for a high level of modularity and parallelized implementation efforts, as well as runtime upgradability of the Hansa functionality.

• Authority
• Caching
• Hosts
• Layout
• Network

The SPI allows for third-party enhancements of the Hansa core/standard functionality.
It is probably a good idea to read about the Hansa Bootstrap process if you intend to write your own enhancements.

How to use Hansa in various systems.

Hansa is very non-intrusive and it is possible to Hansa enable many application without writing any code. Practically every application that understands the URL concept can take advantage of many Hansa features. We will try to list how this is done for common applications, and if your application is not listed, you can probably find out from the other cases how to go about it. (And please update this page with the details if you succeed.)

Stand-alone applications

OSGi

You need to load the Hansa Bootstrap bundle, i.e. the hansa-bootstrap.jar, which will by default load all the other needed bundles, of the latest version, just like the command-line Hansa does. OSGi is very co-operative when it comes to the URL space, so no other action is required prior to starting the OSGi framework itself. You can either load the Hansa Bootstrap manually (which will be reloaded upon next non-clean start of the framework), or you see below which file and entry to modify for each of the OpenSource implementations below.

Knopflerfish

Felix

Equinox

Tomcat

Jetty

JBoss

Geronimo

Internal Operations

See this page for more information on how Hansa works internally, and how to extend Hansa with more functionality. The Hansa Bootstrap page also covers the initial startup of Hansa.