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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
