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 Sutic <le...@inspireinfrastructure.com> on 2002/09/02 19:06:53 UTC
[Attn: Peter D] Services, roles, etc...
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?
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 it is, I really do not see the need for the <key/> element. It
should be the same as the <interface/> element.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Attn: Peter D] Services, roles, etc...
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
OK, then it makes perfect sense.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Attn: Peter D] Services, roles, etc...
Posted by Peter Donald <pe...@apache.org>.
On Wed, 4 Sep 2002 18:25, Leo Sutic wrote:
> 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.
So equivelent to Cocoons (and myrmidons) short-name? Essentially just a short
name that maps to the Service (or Role in Cocoon/myrmidon terminology). So
that "conn-manager" is a name for the type.
> 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.
Okay - I get you. The first case is the one I have been proposing. However
that differs from what I interpreted you to mean just above. The key (whether
it be "abcdefg" or "harry-potter" is local to and defined by the consumer. It
is the containers responsibility to map a component into the component local
namespace (ie using the "abcdefg" or "harry-potter" keys).
I guess what I am saying is that we can have a shortname "conn-manager" that
refers to the service type. I believe Stephen did this at one stage for
blocks using their "name" field.
However this is not necessarily related to the name of the key that consumers
use to get a reference to the component.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Attn: Peter D] Services, roles, etc...
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Attn: Peter D] Services, roles, etc...
Posted by Peter Donald <pe...@apache.org>.
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.
> 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?
--
Cheers,
Peter Donald
'Most men would rather die than think. Many do.'
Bertrand Russell
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Attn: Peter D] Services, roles, etc...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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?
Seems like no... It can be also cm connecm, or whatever.
But...
This Role=Interface+Metadata is biting us as a definition throughout
(correct spelling? ;-) the Avalon history.
Remember for example the role=interfaceVSlookup key debacle of some
months ago.
Now, we have said that Role=Interface+Metadata.
The poin now is: how to describe it?
The most language neutral way is by defining it in an XML descriptor
*without* interface names and define a set of rules for language bindings.
OR
Define it in the language like Java interface+javadocs4xdoclet and have
the doclet create the info file.
Either way, we have a descriptor, that describes a role.
As a moniker, it has a name, which is now the key, a set of attributes,
and an interface descriptor.
What we need is a means of describing the interface.
<role id="org/apache/avalon/connectionmanager">
<attribute name="lenient" value="true">
It tells Avalon to...
</attribute>
<action name="getconnection">
It gets a connection for...
<param name="keepalive" type="boolean">
It specifies if it has to...
</param>
</action>
</provides>
Would translate automatically into:
/**
* @lenient true
**/
interface ConnectionManager{
/**
* It gets a connection for...
* @param keepalive t specifies if it has to...
**/
public getConnection( boolean keepalive ){
}
}
> 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 it is, I really do not see the need for the <key/> element. It
> should be the same as the <interface/> element.
The key and the interface in fact have to be the same, as you say.
I cannot have the same interface used with different attributes for
different keys in Java.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>