> On Tue, 3 Sep 2002 03:06, Leo Sutic wrote:
> > Peter,
> >
> > in the following:
> >
> > <provides>
> > <role>
> > <key>conn-manager</key>
> > <interface>org.apache.avalon.ConnManager</interface>
> > </role>
> > </provides>
> >
> > the key, "conn-manager", implies "org.apache.avalon.ConnManager",
> > right?
>
> Ooops - I wrote that didn't I? Eek. Ignore that - it is wrong
> and not meant to
> be there. The key is only meaningful for <requires/> or
> <dependency/> where
> you need to lookup the component using key?
>
> > So isn't the <interface/> element redundant?
> >
> > I assume you will use the <key/> to define exactly what
> attributes may
> > be set for the connection manager. That is, "conn-manager" implies:
> >
> > + A certain interface (org.apache.avalon.ConnManager)
> >
> > + A set of attribute keys (for example, it may declare "is-secure")
> >
> > Is this a correct understanding of the <key/> element?
>
> If this was a <requires/> or <dependency/> tag then yes.
I was more thinking that:
That is, "conn-manager" implies:
+ A certain interface (org.apache.avalon.ConnManager)
+ A set of attribute keys (for example, it may declare "is-secure"),
but it does not imply the actual values of those keys. That is,
the "conn-manager" implies a list of attribute names, but not
the values of those attributes.
> > If it is, I really do not see the need for the <key/> element. It
> > should be the same as the <interface/> element.
>
> There are 2 problems with that. Stephen objects to it on
> principles and names
> the components accorind to a shortname. The second problem is
> that if you use
> 2 services that have the same interface but act in different
> roles you end up
> with keys like
>
> org.apache.avalon.Store/persist
> org.apache.avalon.Store/cache
> org.apache.avalon.Store/spool
> etc.
>
> That make it any clearer what I mean?
OK. Example case:
Consumer HelloWorld:
This is an HTTP server. It uses a connection manager to accept
incoming connections, and then prints out a short "Hello (Secure)
World" message to the client. It accesses the connection manager
via a org.apache.avalon.ConnManager interface, and (due to the
paranoid world we live in) wants HTTPS connections only.
LeosConnectionManagerImpl:
This is an implementation of the org.apache.avalon.ConnManager
interface. It supports HTTPS connections, and this class can
thus be used to provide a connection manager for HelloWorld.
No matter how we go about it, we must have some way for HelloWorld
to explain the need for a connection manager that implements a
certain interface and that can provide HTTPS connections, and
for LeosConnectionManagerImpl to declare that it can supply
those things.
The HTTPS part can be handled with attributes. Let
LeosConnectionManagerImpl
have an attribute "HTTPS:true" and let HelloWorld specify that it wants
a
connection manager with the HTTPS attribute set to true.
We can do this in several ways:
1)
HelloWorld: "When I do a lookup("conn-manager") I want a
org.apache.avalon.ConnManager interface. I expect the implementation
to have the attribute HTTPS set to true."
LeosConnectionManagerImpl: "I implement the
org.apache.avalon.ConnManager
interface, and my HTTPS attribute is set to true."
2)
HelloWorld: "I need something for the role "conn-manager"."
LeosConnectionManagerImpl: "I implement the
org.apache.avalon.ConnManager
interface, and my HTTPS attribute is set to true. If anyone asks for the
role "conn-manager", you should give me to them."
3)
HelloWorld: "I need something for the role "conn-manager"."
LeosConnectionManagerImpl: "I implement the
org.apache.avalon.ConnManager
interface, and my HTTPS attribute is set to true."
Container: "LeosConnectionManagerImpl implements the
org.apache.avalon.ConnManager
interface and has its HTTPS attribute set to true. If anyone asks for
the
role "conn-manager", I shall give give it to them."
-----------------------------------------
The big difference is that in the second case, the "conn-manager" role
is
defined independent of HelloWorld or LeosConnectionManagerImpl. I
believe
this second or third case is the one you expect to handle with the
<key/>
element.
I'm all for the third case, where the role string has container scope,
or
the first case where it has consumer scope. The second case I find
harder
to accept. I just see a load of naming issues.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
