> but, understanding that, is it a policy to discourage the use of the
> ComponentManager outside of compose(), i.e. are the following bad:
no. In the current CM, there's a release() method which is not really
ment to be called inside compose() (though you can do that as well if
you want), but at a later stage.
I'd recommend getting your references as early as possible though (ie
during initialization) if at all possible.
In the new setup, without the release(), that will mean the CM could get
GCed earlier on. Maybe a container could call the GC after initializing
but before the system is "running", for example.
> or
>
> private TypeTwoInterface m_type2;
>
> public void begin()
> {
> m_type2 = (TypeTwoInterface) m_cm.lookup( "TypeTwoInterface" );
> m_type2.begin();
> }
>
> public void foo()
> {
> m_type2.bar()
> }
>
> public void end()
> {
> m_type2.end();
> m_type2 = null; // let the GC clean it up :)
> }
>
>
> why is it wrong for the composer you mention to not be threadsafe? and if
> it declares itself non-threadsafe (or fails to decleare itself
> threadsafe), how is it bad to use a non-threadsafe component over several
> methods (as in the second example above)?
Because there is no guarantee that the same component will not be called
by some other component between begin() and end().
While a container could possibly guarantee this by creating new
instances, that has to do with the contract between container and
component, and not with the contract between component and the
ComponentManager.
Note that a related topic is Berin's thoughts on sessions (also recent).
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
