avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anton Tagunov <atagu...@mail.cnt.ru>
Subject Re: Fortress ServiceManager question
Date Thu, 29 May 2003 18:33:47 GMT
Hello Shash!

SC> I looked at the CVS code last night, and it seems like the latest code
SC> acquires the ServiceManager from the container-manager context, and then 
SC> proceeds to wrap it in a DefaultServiceManager. Is there any reason why the 
SC> wrapping needs to happen?  In our application, we have a specialized lookup 
SC> method that takes a context, so that authorization can be checked when the 
SC> service is obtained.  I have worked around it by later wrapping the 
SC> DefaultServiceManager again in another KeelServiceManager, but it'd be nice 
SC> if Fortress used what it was provided when the container was setup.

It looks like there is no way to avoid that.
We need to add quite a lot of things to ServiceManager
(and even if we needed add one thing we still would have to
do it): LoggerManager, MetaInfoManager, etc.

But please have a look at the AbstractContainer.provideServiceManager()
method that has been added today. Maybe this can make you happier? :-)
You might even subclass FortressServiceManager if you wanted to and
have the smallest hierarchy possible:
   DefaultServiceManager->KeelFortressServiceManager
Does this allow to implement authorization (and do it efficiently)?

SC> But, the majority of changes were because of the use of life-cycle
SC> interfaces like "Contextualizable" to set contexts.

Please also look at the AbstractContainer.provideComponentContext().
Does it address this very problem?

- Anton


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


Mime
View raw message