avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <aok...@bellsouth.net>
Subject RE: A Foolish Consistency
Date Tue, 13 Apr 2004 19:24:19 GMT
Nick,

That's brilliant!

I like it very much.  It's a formula for small, simple and use only what you
need without requiring AF dependency.  I'm sure this is something all
container camps would appreciate.  It also fosters easy interoperability
between containers.  

	--Alex

> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Tuesday, April 13, 2004 1:32 AM
> To: Avalon Developers List
> Subject: Re: A Foolish Consistency
> 
> 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




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


Mime
View raw message