You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Sergey M Vladimirov <bs...@land.ru> on 2004/08/03 20:12:34 UTC

Re[2]: Lookup the collection (I had lost thread)

Good time, Berin.

You wrote 3 august 2004 г., 21:52:24:

My dictionary (Lingvo) is going to be crazy from your message ;)

BL> Start with what is the real need here.  Then look at the current
BL> solutions, and what we see as a deficiency.  I've kind of gotten
BL> lost, so this is what I am missing here.
Ok. By points.

1. I need solution to retrieve all components, that can share one
interface, like filter, to provide choice from one of them to user at
runtime.

2. Solutions in current implementation is add "[]" or "{}" to key and
try to retrieve by such key.

3. Deficiency - no standard mechanism to lookup collection of
components.

-- 
With best regards,
 Sergey                          mailto:bsp@land.ru


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Re: Re[2]: Lookup the collection (I had lost thread)

Posted by Leo Sutic <le...@gmail.com>.
I think a lookupAll would be the best solution.

Security would be achieved by simply not returning components to the
client unless the client is allowed to see those components.

The problem with the reasoning that went into the security reason is this:

 1. A component must not be allowed to obtain references to components
it is not allowed to access.

 2. A component can obtain a reference to any component whose role it knows.

 3. Therefore, it should not be allowed to know all roles in the system.

The problems are between 2 and 3:

 1. The role is predictable and thus not a secret key and we can't
treat it as such.

 2. We can do one better - since we can intercept any call to lookup,
we can implement any security checks there. If we don't want component
A to lookup component B, then we can just not ever return B to A.
Irrespective of lookup or a future lookupAll or a future
listAllRolesInManager.

So the security reason is ignorable.

I'd do this:

Keep Component/ServiceManager as-is. Create a ComponentLocator /
ServiceLocator class, and mark it as optional. Then create a lifecycle
stage for it.

/LS

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org