Hi Peter, answer inline:
> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 11, 2002 7:56 AM
>
>
> 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.
There is so much in a word....
For me an URL is a component. Really! But...
> 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.
...this makes it much less confusing. =:o)
Ok, what I am proposing is for Avalon (Framework + Excalibur) 5 to have a
brand new ComponentManager which could provide the core functionality for
the ServiceManager (now called ComponentManager).
So, Avalon would get BOTH a Service Manager and a Component Manager. This
would make the framework quite a bit more generic and I think it would be
of better use for projects like Ant-Myrmidon and Cocoon.
I mean, my "Sitemap" does a lot of the same that Cocoon's Sitemap does and
I just use my standard ComponentManager and Configurator functionality for
that. They have to do a lot more manually I think.
And then, this would be interesting for most servers. I mean, I could
develop "mailets" with my xml-configured-components + scripting
architecture.
=:o)
> > 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 ?
Yes, you understood it well.
Even in a persistent Architecture it would help to ensure that all
resources are released when you shut it down, but for such architecture
you would probably not need the "token".
However, most persistent Architectures have some bit where they could
use this token thing:
- Imagine James providing access to (my flavor of) components for a
mailet and ensuring all resources used for a request would be
closed;
- Imagine webapp reload on a Servlet Container. With Servlet
containers providing things like user validation via database and
some J2EE services, you want to clean up that kind of stuff when
you reload a webapp;
- Same thing for mailet reload?
> --
> Cheers,
>
> Pete
>
> ----------------------------------------------
> Money is how people with no talent keep score.
> ----------------------------------------------
Sometimes it must be fun not to have talent in that way!
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
