Paulo Gaspar wrote:
> 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...
That's the problem with the word Component. It is overused so many
times, and noone defines it very well. Maybe I should write a book ;)
>>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.
Yea. I was looking at your code snippet, and I finally have a couple of
comments. First, I was really looking for how a Client component uses the
ComponentManager you have, and how the ComponentManager itself is set up.
Second, your system is based on the JavaBeans approach, and features an
Active configuration system. By that I mean that you expose all sorts
of configuration points via setters and getters as opposed to reading
a passive configuration object and configuring the component based on
that.
I prefer the passive configuration system that Avalon uses due to the fact
that I have tight control over what settings are applied and when. Secondly,
I prefer it due to the fact that the interface of the Component isn't muddied
by what amounts to Configuration points.
However, that is a matter of preference.
>>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?
Actually, the Token approach would work quite well for Cocoon who wants
the ability to lookup a component to use for the life of a request,
and release them all when the request is over.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
