Lookup the collection (I had lost thread)

[Sergey M Vladimirov <bs...@land.ru>]

Good time, devs.

Sorry for this message, but I will try to retry or rewrite something.

Carsten Ziegeler <cz...@s-und-n.de>  (S&N AG):
>>(List)ServiceManager.lookupAll(Filter.class).iterator;
> Hmm, yes, although it might be that this is against one of the
> basic design principles of Avalon: security.

For this reason I provide solution: Collectable interface.

But answers of Niclas Hedhman and Berin Loritsch move me to nowhere.

I don't see any other solution with IoC template for such task (lookup
collection) and cann't see any security problem in provioded solution.

Security: If component know Interface (Key)  for one class, it can
resolve it. If component know subinterface of Collectable, it can
resolve all components, that implement such interface (not only
Collectable, but subinterface of Collectable). Is there any security
problem?

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

[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

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

[Sergey M Vladimirov <bs...@land.ru>]

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: Lookup the collection (I had lost thread)

[Berin Loritsch <bl...@d-haven.org>]

Sergey M Vladimirov wrote:
> Good time, devs.
> 
> Sorry for this message, but I will try to retry or rewrite something.
> 
> Carsten Ziegeler <cz...@s-und-n.de>  (S&N AG):
> 
>>>(List)ServiceManager.lookupAll(Filter.class).iterator;
>>
>>Hmm, yes, although it might be that this is against one of the
>>basic design principles of Avalon: security.
> 
> 
> For this reason I provide solution: Collectable interface.
> 
> But answers of Niclas Hedhman and Berin Loritsch move me to nowhere.
> 
> I don't see any other solution with IoC template for such task (lookup
> collection) and cann't see any security problem in provioded solution.
> 
> Security: If component know Interface (Key)  for one class, it can
> resolve it. If component know subinterface of Collectable, it can
> resolve all components, that implement such interface (not only
> Collectable, but subinterface of Collectable). Is there any security
> problem?

A common falacy is that one might think they can actually achieve
total security.  This is impossible, but it is quite possible to get
something so complex and so convoluted that it is unusable.

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

-- 

"Programming today is a race between software engineers striving to 
build bigger and better idiot-proof programs, and the Universe trying to 
produce bigger and better idiots. So far, the Universe is winning."
                 - Rich Cook


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