On Mon, Jul 08, 2002 at 01:04:29PM -0400, Berin Loritsch wrote:
> > From: Marcus Crafter [mailto:[EMAIL PROTECTED]] 
> > 
> >     1. How should a Container get a reference to its own CM/SM - via
> >     getComponentManager() or via compose()/service().
> 
>       The CM/SM is merely a lookup interface for the internals of the
>       Container.  The getComponentManager()/getServiceManager() methods
>       are factory methods so that each client can have its own copy.
> 
>       This is a plus, because we can safely delay thread contention issues
>       until the last possible minute.
> 
> >     public void initialize() throws Exception
> >     {
> >             super.initialize();
> >             m_manager = getComponentManager();
> >     }
> 
> 
>       ?!

        Yes, terrible isn't it :)

>       Danger Will Robinson!  Danger!  Subversion of Control is bad.
>       If an AbstractContainer is Composable or Serviceable it will get
>       the parent manager from the compose()/service() methods.  It is
>       the ContainerManager's responsibility to provide one.  If it doesn't
>       then there is a bug.

        Currently AbstractContainer is both Composable and Serviceable, however
        compose() and service() are only called on the container, if a
        parent CM or SM is provided via the ContextBuilder.
        
        This means if you want a componentManager reference inside of a
        container, you have to do it in initialize or on the fly :(
        
        This is why I was proposing that the component manager reference
        be set to a protected variable in compose(), and that compose
        always be called, either with a valid parent CM, or null as the
        parent CM if none was given.
        
> >     IMHO, I think it would be better if the component/service manager
> >     was available in a protected m_componentManager variable at the
> >     AbstractContainer level, after compose()/service() is called.
> 
>       There is a huge difference between a parent CM and the managed
>       component's CM.  The AbstractContainer creates a new ServiceManager
>       All the components created and managed by Fortress are given a
>       FortressComponentManager or a FortressServiceManager.  If the
>       container does not handle that type of component, it will lookup
>       in the parent component manager.
> 
>       Don't confuse the two CMs.

        Ok - I understand the difference between the 2 CM's, the question
        is how can I fix it so I don't have to write the code above to get
        a reference to the component manager ?
        
        At the moment you have to do:
        
        public void initialize()
        {
                super.initialize();
                m_manager = getComponentManager();
        }
        
        which I don't like either, or something like:
        
        public void someMethodOnMyContainer()
        {
                ComponentManager cm = getComponentManager();
                MyComponent comp = (MyComponent) cm.lookup(MyComponent.ROLE);
                ...
                ...
                cm.release(comp);
        }
        
        which is ok, but requires calling getComponentManager() each time
        you want the reference. 
        
        I'd find it better if we could allow the component manager reference 
        to be set (like how we advocate when writing Components) in compose():
        
        (in AbstractContainer)
        
        public void compose(ComponentManager cm)
                throws ComponentException
        {
                // parent component manager specified
                if (cm != null)
                {
                        m_componentManager =
                                // this = container
                                // cm = parent CM
                                new FortressComponentManager(this, cm);
                }
                // no parent component manager specified
                else
                {
                        m_componentManager =
                                // this = container
                                new FortressComponentManager(this);
                }
        }
        
        (then we wouldn't need getComponentManager(), as it the CM would
        already be available in m_componentManager, ditto for ServiceManager).
        
        This does what you said above. That is, if a component of a
        particular type is not supported by the Container, then its
        fetched from the parent CM - and it also means one doesn't have to
        write mucky initialize() methods or excessive on-the-fly
        getComponentManager() calls to get a CM reference.
        
        Is that clearer ? or have I missed something ?

> >     Currently in Fortress you can only have a Composable or 
> > a Servicable
> >     Container, not both *but* it is possible to have an external
> >     ServiceManager parenting a ComponentManager inside the 
> > container and
> >     vice versa.
> 
> We have a way of wrapping the ComponentManager or ServiceManager
> so that they can be used interchangeably.

        This is what I meant by 'together' - how can they be used
        interchangeably - If a wrapped ServiceManager returns an Object, the
        cast to Component could fail, and we have no way of preventing this
        from happening. Isn't this a danger we should fix ?
        
        Cheers,
        
        Marcus

-- 
        .....
     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&
           \_&&&&'
          &&&&.
    &&&&&&&:

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to