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