Paulo Gaspar wrote:
> GREAT!
>
> I am using a lot of Avalon stuff in my Web-apps framework and one
> of the stronger reasons I am using modified Avalon code instead
> of the real thing is just the use of interfaces like those:
> - ThreadSafe;
> - SingleThreaded;
> - Poolable;
> and even
> - Component;
>
> Forcing a component to implement a load of interface markers in
> order to be used in the framework makes it harder to:
> 1. Use 3rd party components with Avalon;
> 2. Having Avalon components used by others.
>
> Because:
> 1. More work wrapping/inheriting from the original component in
> order to integrate it with Avalon;
> 2. Avalon components having more dependencies on other Avalon
> parts.
>
> Actually, the policy of forcing the use of those interfaces makes
> Avalon a bit monolithic. (Hey, before you flame me notice that I
> am saying just "a bit"!!!)
Can I ask a couple questions? How do you propose to handle the difference
between a Component that is ThreadSafe (i.e. can be used simultaneously
by multiple clients) and one that is SingleThreaded (i.e. must have a
unique instance for each client)?
They do have purpose. If all you deal with are ThreadSafe Components,
then the DefaultComponentManager would be enough for you. Unfortunately,
not all projects have that luxury. Creating a new instance for every
client is wasteful and causes more work for the server than is necessary.
The next question is why make everything more "bean" like. JavaBeans,
while usable, do have a distinct disadvantage in that they are not
clearly marked.
> My pool, database connection pool, component manager, cache and
> other generic "component managers" only impose interfaces on
> component factories and similar "per component class" adapters.
> (Hum... I am sure Peter would pick a better vocabulary!)
>
>
> The roles idea is interesting and works very well when we are
> talking about the roles managed by a ComponentManager. BUT it is
> confusing for a newbie to have all those interface defining
> roles, especially when some are just markers.
Hopefully you have Components that interact, and therefore provide
an interface. Do not confuse the difference between a Role and a
Lifecycle interface.
A Role defines the logical use of the Component in the system. If
the Role interface extends the Component interface, all the hard
work is done for you and you don't have to recast the Component
to release it.
> If you change this one I will only miss having an easy to use
> component manager that can manage several components for the same
> role (naming them). If one day you want to do this one, I would
> like to contribute.
We had explored this in the past. We had big, very impassioned
discussions. The result of that is the ComponentSelector interface.
You use a ComponentManager to get the ComponentSelector for a role
that will have many implementations. The ComponentSelector will
select your exact implementation of the Role based on an arbitrary
Object as a hint (the most common being a string name).
--
"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]>
