avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject The Component Lifestyle
Date Sat, 11 May 2002 12:06:54 GMT
We have a neat definition of the component lifecycle that is quite
rock-solid and useful (http://jakarta.apache.org/
avalon/framework/reference-the-lifecycle.html).

We also have a less formal definition of component lifestyle. There's
some stuff in Berin's Developing with Avalon (in
http://jakarta.apache.org/avalon/developing/framework.html), as well as
in the mailing list archives.

I think now is the time to start thinking about a formal definition of
component lifestyle.

definition: "The component lifestyle defines in which environment the
component can be used."

analogy: keeping it military-style, you can have many soldiers
(components) that basically function the same way (same lifecycle), but
where they can be used in different missions (different lifestyle). Some
may only be able to work alone (SingleThreaded), while others are good
teamplayers (ThreadSafe). Some may be easily made active and inactive
(Poolable). Special types of soldiers can be frozen in a cryonic (sp?)
chamber, transported across the star system and then be thawed and sent
back into battle (Serializable).

hmm...help?

Basically, we define a lifestyle through the implementation of marker
interfaces, just like we do with the lifecycle. Candidates:

Runnable
ThreadSafe
SingleThreaded
Poolable
Singleton (new)
Serializable

Defining these well means that the ComponentManager can adapt its
behaviour based on the allowed lifestyles.

Runnable is pretty much related to ThreadSafe and SingleThreaded. You
could see ThreadSafe as our replacement of Runnable.

ThreadSafe, SingleThreaded and Poolable are well-known and in use
throughout avalon. They're cool; we've defined what coupling of these
three with the various lifecycle interfaces means.

While the Singleton pattern doesn't really fit in well with the
Component/Container/ComponentManager idea, taking it into account eases
the process of avalonizing existing components (ie it would make
integration with Turbine's Fulcrum easier).

Serializable allows for storage of component state. In avalon, this
state consists of Configuration, Context, Parameters and perhaps some
component-specific state that doesn't fit into those three. We could
have a Serializable that extends the java interface, and then a utility
that would serialize based on configuration, context and parameters.

thoughts?

- Leo



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


Mime
View raw message