avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Fresh Perspective
Date Thu, 20 Jun 2002 09:25:19 GMT


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> Sent: den 19 juni 2002 22:15
> To: 'Avalon Developers List'
> Subject: RE: Fresh Perspective
> 
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > 
> > Now: We add a second mail server C that
> > also satisfies D. This in itself is not a problem, as we
> > can assume that unless anything is specified, C and B
> > are interchangeable. We can also fairly easily add some
> > extra info to A saying that "when you ask for a mail server,
> > you will get B, and never C":
> > 
> >   <component class="A">
> >     <!-- makes sure that B provides the mail-server for A -->
> >     <provide role="mail-server" via="B"/> 
> >   </component>
> >   
> >   <component class="B"/>  <!-- provides mail-server -->
> > 
> >   <component class="C"/>  <!-- provides mail-server -->
> > 
> > So the addition of C isn't really a problem. We can "override" the 
> > assembler's heurstics and tell it to pick a certain implementation. 
> > (This is basically the component-local namespaces proposal.)
> 
> 
> Leo, I would always advocate separating yourself from depending
> on specific instances or implementations of a component.  It is
> generally a bad thing as it can have serious consequences later
> on.

That wasn't really my point. It was that you have two components
that supply the same service, but that you can solve the abiguity
by statically selecting one of them *at assembly time*. My second
example was for a resolution that could not be solved at assembly
time.
 
/LS


--
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