avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: A Foolish Consistency
Date Tue, 13 Apr 2004 05:32:19 GMT
On Tuesday 13 April 2004 12:31, Noel J. Bergman wrote:
> > On the other hand there is people that won't need such a monster. Only a
> > simple container to embedded and run his components. No complex Meta,
> > repository, big spec of components/container semantics and behaviors,
> > rigid rules.
>
> Niclas' most recent message seemed to show room to work.  He allowed that
> it is important for a container to know that a component is able to work in
> the container's environment, which allows for dialects, so long as there
> are well-defined ways to express those requirements.  He specifically
> mentioned both an enterprise scope and a picocontainer as potential
> container scales.

Everyone in the 'lightweight camp' seems to make a 

    "Strict Contract" == "Huge Contract"

And I think that is where the main mindset block is sitting.

If Specifications are 'stackable' but small, I can make a "Startable" 
specification, written on a single page or less, independently of the 
"Configurable" contract.

Let's take the Startable specification as an example (forget whether the 
semantics are exactly correct and complete or not);

(All "called" is referring to "called by the container".)
1. The component has one method named start() and one method named stop().
2. Both these methods may throw any Exception.
3. The start() method must be called after all other initalization has 
occurred, and the component is in operational state.
4. The start() method may not be called more than once, without an stop() 
method call in between.
5. The stop() method can only be called after the start() method.
6. The start() method must return within limited amount of time.

So far so good. We could also include
7. The component must implement the interface 
org.apache.avalon.framework.activity.Startable.

So we have a 'conflict'. If we do (7), then it is a Avalon Framework Only 
specification, and if we don't, Fortress (for instance) would have to be more 
complex and make calls via Reflection. Also, (7) is a "container require from 
component", whereas (1)-(6) is "component require from container".

Solution;  
We make two different specifications, where (1)-(6) is,
    * Generic Startable Specification (component require from container )
and (7) is 
    * AF4 Startable Specification (container require from component )

Then declare your typical AF4 component 

    MyComponent requires GenericStartableSpecification
    MyComponent compliesWith AvalonStartableSpecification

where the first is a requirement by the component that the container must 
fulfill and the second is a declaration that the Startable interface is 
available. (HOW such a declaration is made is not part of this example.)

Fortress logic would be (semi-code);

if( component.requires( "Generic Startable Specification" ) )
{
    if( component.compliesWith( "Avalon Startable Specification" ) )
        canHandle( component );
    else
        canNotHandle( component );
}
else
{
    fine();
}

I hope that I have managed to show with the above example;

1. Specifications should be small.
2. Components can mix and match what they require, request and complyWith.
3. That Avalon today already contain a lot of these specs, but lumped together 
under the AF4 umbrella, making it an 'all-or-nothing' (just like EJB) spec.
4. Containers can choose to implement specifications.
5. Containers MUST know the "requires" concept and refuse components that 
declares "requires" on specifications that the container does not implement.

The AvalonNG would be all about making these specifications, one at a time, 
starting with the AF4 stuff we would like to keep, and tools for component 
authors to generate the declarations.

What do you ALL think?

Niclas


-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message