On Fri, 11 Jan 2002 04:55, Paulo Gaspar wrote:
> > At the moment, the CM does one thing and does it very well -
> > handles *components*.
>
> Now, just tell me how specific (not-do-general) the "component"
> concept is to you?
> =;o)
I agree with Leo that "component" concept is definetly not meant to be a
generic object description. You should not be able to put in raw objects like
ClassLoader, Datagrams, URLs and so forth - they are not components.
It may be clearer to use the term ServiceManager rather than ComponentManager
because that has a easier to grok description of what a CM is meant to do.
For sharing of generic resources that are not services but data then Context
is probably the place for it.
> I prefer the way I solved the problem - the "token" way. You just pass
> some token that identifies your task and you can release all components
> in a single step. This "token" can just be the current thread, like
> this:
>
> Object myToken = Thread.currentThread();
>
> try
> {
> MyClass1 cmp1 = (MyClass1)cm.lookup(myToken, "myRole1", "myHint1");
> MyClass2 cmp2 = (MyClass2)cm.lookup(myToken, "myRole2", "myHint2");
> MyClass3 cmp3 = (MyClass3)cm.lookup(myToken, "myRole3", "myHint3");
>
> // And now lets do a lot of stuff...
>
> ...
>
> // ...a lot of stuff done.
> }
> finally
> {
> cm.releaseAll(myToken);
> }
token == transaction of components ? Nice idea. SO for each "symphony" you
are guarenteed that you release your components and so forth right? This is
more aimed at a request based architecture rather than persistent service
based architecture ?
--
Cheers,
Pete
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
