Re: Loom viability

On Tue, 16 Dec 2003 04:45 am, Terry Laurenzo wrote:
> When is a Loom release planned? 

Essentially when someone wants a release. We are close to releasing in terms 
of things that need doing but there has not been sufficient motivation at 
this stage. ATM I just use a CVS snapshot in production but if you need a 
release we can certainly work towards doing one. It should only take a few 
hours to finish up the code and after that we just need to go through the 
release process etc.

> My shop and I are what could be called
> "Phoenix refugees".  We have a large investment in the Phoenix
> platform.  One of the primary problems that I have observed with Avalon
> over the years is that it tends to drift towards "ivory tower" thinking
> quite often.  It seems that radical changes of direction happen
> regularly without a huge eye towards maintaining compatibility (this is
> just an observation... please don't flame me).  Just from browsing the
> JContainer site and the DNA library (which looks a lot like Avalon
> framework but without all of the silly package distinctions), it seems
> that this project is focused more on real-world problems than Avalon
> is/was.

The aim is essentially to be a more practical solution to problems. All of the 
committers here are here because we have real world products based on 
Phoenix/Loom and can not afford to make any radical, backwards incompatible 
changes.

> 1.  In my environment, it is infeasible to introduce an entirely new
> "top level" container.
...snip...
> Are there any plans for supporting such a paradigm?  If not, are there
> plans for at least shoring up the internal Loom kernel structures so
> that a third party implementation such as this would be relatively
> stable from version to version?  Assuming you are not opposed to such
> an idea, would you care for code contributions that allowed Loom to be
> run in this embedded mode?

A lot of people have asked for this and it is a very desired feature but we 
just never got around to implementing it because none of the core committers 
ever needed it that bad. At one stage I helped design a generic API for this. 
I have attached it to this email. 

Then there was a more specific Phoenix-oriented API layer that went something 
like

PhoenixConfig b = ...;
b.setCoreClassLoader( myClassLoader );
b.setConfigURL( configFile.URL() );
b.setAssemblyURL( assemblyFile.URL() );
etc.

ComponentContainer cc = 
  (ComponentContainer) ContainerManager.create( b.toData() );

or something similar. If you are familiar with FortressConfig from fortress 
container it is similar to that except that it is generalized.

Anyways I would be happy to accept a code donation or help you develope an 
embeddors api. The main reason it never got done was that no one finished it 
off. 

> 2.  One of the features which I believe made Phoenix attractive arrived
> in the 4.1 developer branch.  This was the notations around specifying
> maps or arrays of dependencies (appending [] or {} to the role).  It
> seems that the rest of the Avalon community is stuck in some kind of
> religious war revolving around whether ServiceSelector is evil and what
> to do about it.  I thought that the multi-dependency notation was a
> good solution to this problem that no one seems to like but clearly
> needs a solution.  Is this functionality sanctioned in Loom?  Are you
> planning any extensions to it?

The functionality still exists and I dont know of any plans to extend it but 
it may happen if people request extensions ;)

> 3. It is clear that Loom and the JContainer project are intended to be
> complete forks of Avalon.  My observation is that DNA is analogous to
> Avalon framework (with much simplified names).  This is all well and
> good, but is there a commitment to keep Loom capable of hosting
> components/blocks written to the Avalon framework interfaces as opposed
> to the DNA interfaces?

ATM Loom does not even support DNA components. In the future we plan to 
support any component API that it is possible to imagine including DNA, 
Avalon, Pico etc. As long as someone needs the Avalon interfaces we will be 
supporting them in loom.

Anyways - no time atm but should be able to talk more after new years if you 
want ;)

-- 
Cheers,

Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience           |
*-----------------------------------------------------*

/*
 * Copyright (C) The JContainer Group. All rights reserved.
 *
 * This software is published under the terms of the JContainer
 * Software License version 1.1, a copy of which has been included
 * with this distribution in the LICENSE.txt file.
 */
package org.jcontainer.loom.tools.creator;

import java.util.Map;

/**
 * This defines the interface via which containers are created.
 * The notion of container is suitable vague to allow arbitary
 * objects to be created as containers - not necessarily related
 * to Avalon containers in anyway.
 *
 * @author <a href="mailto:peter at realityforge.org">Peter Donald</a>
 * @version $Revision: 1.1 $ $Date: 2003/06/29 01:09:03 $
 */
public interface ContainerFactory
{
    /**
     * Create an instance of container using specified input data.
     *
     * @param data the initial config data for container
     * @return the newly created container
     * @throws java.lang.Exception if unable to create a container
     */
    Object create( Map data )
        throws Exception;

    /**
     * Destroy a container created with this factory.
     *
     * @param container the container
     * @throws java.lang.Exception if unable to destroy container
     */
    void destroy( Object container )
        throws Exception;
}

/*
 * Copyright (C) The JContainer Group. All rights reserved.
 *
 * This software is published under the terms of the JContainer
 * Software License version 1.1, a copy of which has been included
 * with this distribution in the LICENSE.txt file.
 */
package org.jcontainer.loom.tools.creator;

import java.util.Map;
import java.util.WeakHashMap;
import org.jcontainer.loom.tools.creator.ContainerFactory;

/**
 * This defines the interface via which containers are created.
 * The notion of container is suitable vague to allow arbitary
 * objects to be created as containers - not necessarily related
 * to Avalon containers in anyway.
 *
 * @author <a href="mailto:peter at realityforge.org">Peter Donald</a>
 * @version $Revision: 1.1 $ $Date: 2003/06/29 01:09:03 $
 */
public final class ContainerManager
{
    /**
     * The key used to specify the name of the Container factory.
     */
    public static final String INITIAL_CONTAINER_FACTORY =
        ContainerFactory.class.getName();

    /**
     * Cache of created container->factory map.
     */
    private static final Map c_containers = new WeakHashMap();

    /**
     * Create an instance of container using specified input data.
     *
     * @param data the initial config data for container
     * @return the newly created container
     * @throws java.lang.Exception if unable to create a container
     */
    public static Object create( Map data )
        throws Exception
    {
        final String classname = (String)data.remove( INITIAL_CONTAINER_FACTORY );
        if( null == classname )
        {
            final String message = "No INITIAL_CONTAINER_FACTORY specified.";
            throw new Exception( message );
        }
        final Class clazz = Class.forName( classname );
        final ContainerFactory factory = (ContainerFactory)clazz.newInstance();
        final Object container = factory.create( data );
        c_containers.put( container, factory );
        return container;
    }

    /**
     * Destroy a container created with this factory.
     *
     * @param container the container
     * @throws java.lang.Exception if unable to destroy container
     */
    public static void destroy( final Object container )
        throws Exception
    {
        final ContainerFactory factory = (ContainerFactory)c_containers.remove( container );
        if( null == factory )
        {
            final String message = "Container was not created by " +
                "ContainerManager or has already been destroyed.";
            throw new Exception( message );
        }
        factory.destroy( container );
    }
}