You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/05/11 14:06:54 UTC
The Component Lifestyle
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>On Sat, 11 May 2002 22:06, Leo Simons wrote:
>
>
>>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
>>
>>
>
>Interfaces are evil for this sort of thing. They force users to separate
>meta-info across multiple places (ie some in config files, some in .class
>files). I would prefer that all of it be kept in once place which basically
>means putting it all into config files.
>
I totally agree.
Steve.
>
>Eventually I would hope that we would move to using metainfo support built
>into the JVM ala
>
>http://www.jcp.org/jsr/detail/175.jsp
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Peter Donald <pe...@apache.org>.
On Sat, 11 May 2002 22:06, Leo Simons wrote:
> 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
Interfaces are evil for this sort of thing. They force users to separate
meta-info across multiple places (ie some in config files, some in .class
files). I would prefer that all of it be kept in once place which basically
means putting it all into config files.
Eventually I would hope that we would move to using metainfo support built
into the JVM ala
http://www.jcp.org/jsr/detail/175.jsp
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Peter Donald <pe...@apache.org>.
Hi,
Looks like this is go. Could you bugboard this so I remember to do it ? :)
On Sun, 12 May 2002 10:04, Stephen McConnell wrote:
> Peter Donald wrote:
> >On Sun, 12 May 2002 08:55, Stephen McConnell wrote:
> >>Leo Simons wrote:
> >>>>But out-of-date.
> >>>>The lifecycle descriptions are missing a few things:
> >>>>
> >>>> b) Serviceable is missing
> >>>
> >>>where does it go?
> >>
> >>Serviceable should appear wherever Composable appears. Basically
> >>Serviceable is a replacement for Composable - Serviceable takes a
> >>ServiceManager as (as distinct from Composable/ComponentManager).
> >> ServiceManager is independent of the Component marker interface
> >>enabling broader application and support for existing "non-Avalon"
> >>components (because ServiceManager exposes java.lang.Object as distinct
> >>from Component).
> >
> >Which reminds me. Someone suggested that we deprecated the Block interface
> > as it is just a marker interface.
>
> +1
>
> >However we would have to also deprecate the
> >Composable interface within the context of Phoenix as now no Blocks would
> >implement the Component interface. Thoughts on that?
>
> +1
>
> Cheers, Steve.
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>On Sun, 12 May 2002 08:55, Stephen McConnell wrote:
>
>
>>Leo Simons wrote:
>>
>>
>>>>But out-of-date.
>>>>The lifecycle descriptions are missing a few things:
>>>>
>>>> b) Serviceable is missing
>>>>
>>>>
>>>where does it go?
>>>
>>>
>>Serviceable should appear wherever Composable appears. Basically
>>Serviceable is a replacement for Composable - Serviceable takes a
>>ServiceManager as (as distinct from Composable/ComponentManager).
>> ServiceManager is independent of the Component marker interface
>>enabling broader application and support for existing "non-Avalon"
>>components (because ServiceManager exposes java.lang.Object as distinct
>>from Component).
>>
>>
>
>Which reminds me. Someone suggested that we deprecated the Block interface as
>it is just a marker interface.
>
+1
>However we would have to also deprecate the
>Composable interface within the context of Phoenix as now no Blocks would
>implement the Component interface. Thoughts on that?
>
>
+1
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Peter Donald <pe...@apache.org>.
On Sun, 12 May 2002 08:55, Stephen McConnell wrote:
> Leo Simons wrote:
> >>But out-of-date.
> >>The lifecycle descriptions are missing a few things:
> >>
> >> b) Serviceable is missing
> >
> >where does it go?
>
> Serviceable should appear wherever Composable appears. Basically
> Serviceable is a replacement for Composable - Serviceable takes a
> ServiceManager as (as distinct from Composable/ComponentManager).
> ServiceManager is independent of the Component marker interface
> enabling broader application and support for existing "non-Avalon"
> components (because ServiceManager exposes java.lang.Object as distinct
> from Component).
Which reminds me. Someone suggested that we deprecated the Block interface as
it is just a marker interface. However we would have to also deprecate the
Composable interface within the context of Phoenix as now no Blocks would
implement the Component interface. Thoughts on that?
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>>But out-of-date.
>>The lifecycle descriptions are missing a few things:
>>
>> b) Serviceable is missing
>>
>
>where does it go?
>
Serviceable should appear wherever Composable appears. Basically
Serviceable is a replacement for Composable - Serviceable takes a
ServiceManager as (as distinct from Composable/ComponentManager).
ServiceManager is independent of the Component marker interface
enabling broader application and support for existing "non-Avalon"
components (because ServiceManager exposes java.lang.Object as distinct
from Component).
>> a) configurable OR paramerterizable (choice
>>
>
>when did this happen? Why?
>
More than a year or two ago.
From the Javadoc:
public interface Configurable
This interface should be implemented by classes that need to
be configured with custom parameters before initialization.
The contract surrounding a Configurable is that the instantiating
entity must call the configure method before it is valid. The
configure method must be called after the constructor, and before
any other method.
Note that this interface is incompatible with Parameterizable.
The above semantics are enforced in both Merlin and Phoenix - I don't
know what the status is with ECM (because I don;t use ECM).
>> b) composable OR serviceable (choice)
>>
>
>you probably ment a), b), c) :D
>
I did :-)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Leo Simons <le...@apache.org>.
> But out-of-date.
> The lifecycle descriptions are missing a few things:
>
> b) Serviceable is missing
where does it go?
> a) configurable OR paramerterizable (choice)
when did this happen? Why?
> b) composable OR serviceable (choice)
you probably ment a), b), c) :D
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: The Component Lifestyle
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>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).
>
>
But out-of-date.
The lifecycle descriptions are missing a few things:
b) Serviceable is missing
a) configurable OR paramerterizable (choice)
b) composable OR serviceable (choice)
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The Component Lifestyle
Posted by Leo Simons <le...@apache.org>.
> Berin and I were through this debate when we created Fortress.
Ah, read up on this...wonder why I missed all that.
Anyways, this discussion was very focused on implementation. That is
something I consider of secondary interest here. It just seems that
there is this undocumented concept of "component lifestyle" that we
should capture in some way, just like we did with the lifecycle.
Whether we do so using marker interfaces, more concrete interfaces,
custom javadoc tags or xml descriptors is not my concern atm (though
doing so using XML means an automatic added complexity layer as you need
an xml parser etc etc).
I feel fortress goes some way into capturing this, as do our other
containers, as does "Developing with Avalon", but the concept is not as
rock-solid as it should be.
> My point is this: Some of the interfaces you propose define different
> things.
True (and there's no proposal, just thoughts). The thing they have in
common is that they are, or can be, of concern to the container, while
not being part of the component lifecycle definition.
I'm sure that once we formalize the lifestyle, we will identify more
clearly these kinds of container concerns. Also, once we do so, we can
point out which of those concerns a particular container addresses.
cheers,
- Leo
PS: while it is pragmatic, it'd be nice if you wouldn't address me as
"Simons"...reminds me too much of annoying 8th grade school teachers :D
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The Component Lifestyle
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> Simons,
>
> Berin and I were through this debate when we created Fortress.
> I argued, just as you do, for marker interfaces. My rationale was that
> the information about how a component should be handled should be
> close to the component itself, and that it was one point where
> java reflection really could shine.
Don't forget Peter in this too! He is not in favor of marker
interfaces
>
> Berin, however, added a handler attribute to the container
> configuration that specified how the component should be handled.
> For example, you would have:
>
> <component role="some.Role"
> class="some.Class"
> handler="handlers.ThreadSafe"/>
>
> for ThreadSafe components.
<snip/>
Another issue arose from the Cocoon developers. Components were added,
and the developers didn't realize that they should add marker interfaces
for the ECM to treat the components as ThreadSafe, Poolable, etc.
As a result, the overall Cocoon project had a feeling of being slow and
heavy because a new component was created for every ECM request.
People are forgetful about the marker interfaces because they do not
have any methods to implement. I'm sure its sociological or something.
However, most people don't forget to make the descriptor work for them
properly. :/ I'm still scratching my head on that one--nevertheless,
it's what I've observed.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: The Component Lifestyle
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Simons,
Berin and I were through this debate when we created Fortress.
I argued, just as you do, for marker interfaces. My rationale was that
the information about how a component should be handled should be
close to the component itself, and that it was one point where
java reflection really could shine.
Berin, however, added a handler attribute to the container
configuration that specified how the component should be handled.
For example, you would have:
<component role="some.Role"
class="some.Class"
handler="handlers.ThreadSafe"/>
for ThreadSafe components.
The end of that discussion was:
http://marc.theaimsgroup.com/?l=avalon-dev&m=101533719408368&w=2
BL> >>>>YES! Absolutely. I want to remove the dependancies on marker
BL> >>>>interfaces in general.
BL> >>>>
BL> >>>>
LS> >>>I think marker interfaces are great
LS> >>>
BL> >>The problem is when you have a deep implementation or interface
BL> >>hierarchy. If any superclass implements one lifestyle interface,
then
BL> >>you cannot change it down the line.
BL> >>
LS> >
LS> > You'd have an ordering ThreadSafe < PerThread < Poolable <
SingleThreaded,
LS> > but yeah, I can see that we're trying to be a little too smart
here.
BL>
BL> Not to mention that it is quite awkward when some of those classes
are
BL> in framework, some are in Excalibur, but they are not all in one
BL> package. Furthermore, this way we don't have to change the library
if
BL> we find a new way to manage component instances (like I did with the
BL> Per-Thread policy).
My point is this: Some of the interfaces you propose define different
things.
ThreadSafe, SingleThreaded, etc. really only define how the component
should be handled by a container. Serializable (Persistable?) define
component abilities, and Initializable etc. define what lifecycle
stages this component is interested in.
The first bunch are not really requirements. A ThreadSafe component
can be handled as a SingleThreaded, for example. Serializable et al
does not put any requirement at all on the container, it is merely a
"if you want me to do this, then sure, I can do it." Initializable
is a contract that *must* be honored.
After reading Berin's comments above, I'd remove all interfaces that
pertain to the *handling* of the component. (ThreadSafe etc.)
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>