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/06/17 20:44:51 UTC
Extensions to Avalon containers (was: RE: [proposal] avalon 5 ComponentManager interface)
All,
I've repeatedly stated that I have a proposal regarding the
lookup of components - although I have not really specified what
that proposal is. The result is that I have sometimes even apparently
argued against myself.
What I propose is in all simplicity this: The ability to define
a component specific namespace in the container as far as
roles are concerned.
That didn't make much sense, but let's look at an example.
This is the situation in most containers now:
<component role="my.Role" class="MyComponent"/>
<component role="ConnectionManager" class="some.ConnectionManager"/>
All roles, defined for all components in the container,
exist in a single, flat namespace. You can not have two
implementations of the same role, without either using
selectors, or by qualifying the role name. For example,
the ConnectionManager.ROLE + "/SSL" sample.
There is also a problem that appears when you mix
components from different origins: Suppose you have
a component called MyComponent. Then you download from
some website a needed component called OtherComponent.
Both MyComponent and OtherComponent are composers. Both
require a ConnectionManager, which they use ConnectionManager.ROLE
to lookup.
The problem: They want *different* connection managers,
and neither uses a component selector.
<component role="my.Role" class="MyComponent"/>
<component role="ConnectionManager" class="some.ConnectionManager"/>
<component role="other.Role" class="OtherComponent"/>
<!-- DOESN'T WORK! Collides with some.ConnectionManager. -->
<component role="ConnectionManager"
class="some.other.ConnectionManager"/>
So how are you going to solve this? In the current ECM, you can't.
For each role, there may be a single implementation. If you
want more, you have to use component selectors.
Another problem: As above, but you want MyComponent and OtherComponent
to use the *same* connection manager. This time, however, OtherComponent
looks up "connection-manager" and MyComponent looks up
"ConnectionManager".
So what's the role?
My proposal is that for each component in a container, you can
optionally specify new role mappings. The first problem above
would be solved by:
<component role="my.Role" class="MyComponent">
<provide role="ConnectionManager" via="ConnectionManager/some"/>
</component>
<component role="ConnectionManager/some"
class="some.ConnectionManager"/>
<component role="other.Role" class="OtherComponent">
<provide role="ConnectionManager" via="ConnectionManager/other"/>
</component>
<!-- WORKS! No collision any more. -->
<component role="ConnectionManager/other"
class="some.other.ConnectionManager"/>
The second by:
<!-- There is no need to provide a mapping for MyComponent,
as it will lookup "ConnectionManager", which is a valid
role name in the container namespace. -->
<component role="my.Role" class="MyComponent"/>
<component role="ConnectionManager" class="some.ConnectionManager"/>
<component role="other.Role" class="OtherComponent">
<!-- Uses the same connection manager as MyComponent, despite
looking up a different role string. -->
<provide role="connection-manager" via="ConnectionManager"/>
</component>
That is all.
This functionality already exists in Phoenix, if I understand it
correctly, and can be put into Fortress ( = Phortress? :)) without
breaking backwards compatibility.
This does not solve the "what is a hint" problem, it does not
solve runtime mappings for Cocoon. It only solves the
namespace collision issues. (Note that I *will* take credit for
solving those if someone can extract a working solution from the
above. ;) "Oh, yeah, but that was what I said all along..." )
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Extensions to Avalon containers (was: RE: [proposal] avalon 5 ComponentManager interface)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo, please state how your approach would work for the
> use cases I outlined in my other message.
I'll get to that in another proposal (typing it up right now).
Basically I consider this orthogonal, and I'll show how
it can be made to work with hints.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Extensions to Avalon containers (was: RE: [proposal] avalon 5 ComponentManager interface)
Posted by Berin Loritsch <bl...@apache.org>.
Leo, please state how your approach would work for the
use cases I outlined in my other message.
Please ignore the releasing of components for the time being,
as that is not what we are discussing ATM.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Monday, June 17, 2002 2:45 PM
> To: 'Avalon Developers List'
> Subject: Extensions to Avalon containers (was: RE: [proposal]
> avalon 5 ComponentManager interface)
>
>
> All,
>
> I've repeatedly stated that I have a proposal regarding the
> lookup of components - although I have not really specified
> what that proposal is. The result is that I have sometimes
> even apparently argued against myself.
>
> What I propose is in all simplicity this: The ability to
> define a component specific namespace in the container as far
> as roles are concerned.
>
> That didn't make much sense, but let's look at an example.
> This is the situation in most containers now:
>
> <component role="my.Role" class="MyComponent"/>
>
> <component role="ConnectionManager" class="some.ConnectionManager"/>
>
> All roles, defined for all components in the container,
> exist in a single, flat namespace. You can not have two
> implementations of the same role, without either using
> selectors, or by qualifying the role name. For example, the
> ConnectionManager.ROLE + "/SSL" sample.
>
> There is also a problem that appears when you mix
> components from different origins: Suppose you have
> a component called MyComponent. Then you download from
> some website a needed component called OtherComponent.
>
> Both MyComponent and OtherComponent are composers. Both
> require a ConnectionManager, which they use
> ConnectionManager.ROLE to lookup.
>
> The problem: They want *different* connection managers,
> and neither uses a component selector.
>
> <component role="my.Role" class="MyComponent"/>
>
> <component role="ConnectionManager" class="some.ConnectionManager"/>
>
> <component role="other.Role" class="OtherComponent"/>
>
> <!-- DOESN'T WORK! Collides with some.ConnectionManager. -->
> <component role="ConnectionManager"
> class="some.other.ConnectionManager"/>
>
> So how are you going to solve this? In the current ECM, you
> can't. For each role, there may be a single implementation.
> If you want more, you have to use component selectors.
>
> Another problem: As above, but you want MyComponent and
> OtherComponent to use the *same* connection manager. This
> time, however, OtherComponent looks up "connection-manager"
> and MyComponent looks up "ConnectionManager". So what's the role?
>
> My proposal is that for each component in a container, you
> can optionally specify new role mappings. The first problem above
> would be solved by:
>
> <component role="my.Role" class="MyComponent">
> <provide role="ConnectionManager" via="ConnectionManager/some"/>
> </component>
>
> <component role="ConnectionManager/some"
> class="some.ConnectionManager"/>
>
> <component role="other.Role" class="OtherComponent">
> <provide role="ConnectionManager" via="ConnectionManager/other"/>
> </component>
>
> <!-- WORKS! No collision any more. -->
> <component role="ConnectionManager/other"
> class="some.other.ConnectionManager"/>
>
> The second by:
>
> <!-- There is no need to provide a mapping for MyComponent,
> as it will lookup "ConnectionManager", which is a valid
> role name in the container namespace. -->
> <component role="my.Role" class="MyComponent"/>
>
> <component role="ConnectionManager" class="some.ConnectionManager"/>
>
> <component role="other.Role" class="OtherComponent">
> <!-- Uses the same connection manager as MyComponent, despite
> looking up a different role string. -->
> <provide role="connection-manager" via="ConnectionManager"/>
> </component>
>
> That is all.
>
> This functionality already exists in Phoenix, if I understand
> it correctly, and can be put into Fortress ( = Phortress? :))
> without breaking backwards compatibility.
>
> This does not solve the "what is a hint" problem, it does not
> solve runtime mappings for Cocoon. It only solves the
> namespace collision issues. (Note that I *will* take credit
> for solving those if someone can extract a working solution
> from the above. ;) "Oh, yeah, but that was what I said all along..." )
>
> /LS
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>