The purpose of the container is to manage the components under its care. That typically involves various creation and destruction stages, or what we call the LifeCycle. Part of the creation stages is the different needs the component has, such as it may need a Logger, so the container has to provide it, it may need some type of configuration and the container has to provide, and so on.

The container is also responsible to fulfill other concerns of the management contract, such as LifeStyle, Security, Dependencies, JAR handling and so on. Basically, the container should take care of everything required to get the component operational.

Avalon Framework and associated material specifies, among other things a contract between the component and the container. That means that if the component fulfills its obligations, the container will provide the component with its needs. Example; If the component declares that it implements LogEnabled, the container will provide the component with an initialized and ready-to-use Logger instance.

If the component declares that it implements the LogEnabled inteface, a ready-to-use, Logger instance will be provided through the method;

    public void enableLogging( Logger logger )
    {
    }

The Merlin container supports both LogKit and Log4J logging subsystem, and please look at the Avalon Logging subsystem for details.

There are many ways on how to resolve dependencies between components. Avalon uses a method called Lookup Injection, which means that the container will hand over a ServiceManager to the component, if the component implements the Serviceable interface.

    public void service( ServiceManager manager )
    {
    }

The ServiceManager will only provide the component with components that satisfy the dependencies declaration in the component's Type descriptor (.xinfo). If it attempts to lookup anything outside the declared dependencies, the container is expected to throw a ServiceException.

And Merlin is so clever that the component will never be deployed if the dependencies could not be satisfied, so if the component follows its obligations, i.e. only looking up declared dependencies, the container will supply the solution, always!

Many components are generic and can be tweaked into doing slightly different things, according to some settings. We call those settings Configuration, and is supply to the component if the component implements the Configurable interface.

    public void configure( Configuration conf )
    {
    }

The above construct allow for very complex Configurations, using XML nested elements, but not any XML, it must follow certain rules. See Configuration API docs for details.

Contextualization is about establishing a containment context. That means that there must be certain container features available to the component for it to function properly. This is slightly different from normal service dependencies, as context entries can be of any type, such as java.io.File for the standard "urn:avalon:home" context entry.

    public void contextualize( Context context )
    {
    }

It is also possible to create custom context entries. Read more about it.

We have all been in JAR Hell, which means that it is hard to keep track of which Jars are required, and more importantly which version of each. And that is only for your build system. When you start deploying the applications, this grows into a nightmare. This has been highlighted for quite some time within The Apache Software Foundation, and Maven has addressed it for build systems, and recently (March 2004) a new more generic project called Depot started in the incubator, which will address this problem.

Avalon has in the meantime created the Avalon Repository which allows the applications to be distributed without any Jars, and the right versions of the Jars will be picked up at one or many central repositories. This system is compatible with the Maven repositories, so we have instantly access to hundreds of projects at repositories, such as ibiblio.org.

The most straight forward deployment case is the stand-alone server, that is started from the command-line. No programming is required, and there are heaps of command-line arguments available. Read about the details here.

Merlin even supports that it is bootstrapped, with a tiny JAR, which will pick up and start Merlin (or any other compliant artifact) from a central repository. One can on the command-line specify which version of Merlin one wishes to start, and provide the application block reference, effectively selecting which application to start.

If a central repository is not desirable, Merlin's binary distribution contains all that is required to run, except the application block itself, which may either be local or online.

There is actually no difference between a stand-alone server and a stand-alone GUI application. In fact, with good Component Oriented practices, one can completely separate the business logic in the application, and provide a GUI interface or a Web interface simply by changing the block definition file.

Merlin is capable of starting as a Windows NT/XP Service. You can read about how on this page.

If you have an existing application that you want to complement with Avalon component management, without refactoring the whole application into components, you will need to create Merlin embedded inside your application. About 10-15 lines of code is currently required, where the InitialContext is established, the Directives are setup and a Kernel is created. It looks more complicated than it is, but it is extremely powerful, and allows the same features as the stand-alone server, in fact the small bootstrapper in the stand-alone case, does exactly the same thing.

If the Servlet engine allows, it is possible to embedd Merlin inside a Servlet. The code required to do it, can be seen here. It is expected that this Servlet will undergo some enhancement prior to be officially released in the Merlin distribution. This is to ensure maximum usability for our users.

Embedding in Application Servers can prove to be a lot more complicated than in generic Application, since the App Servers very often imposes restrictions on the parts that it hosts, such as security restrictions, classloading restrictions and similar. It is basically a case of trying to get a operating system running inside another operating system, both competing for the same resources.

One of the objectives of the Avalon community is to work out what is possible, and how, and what can not be done, in this area.