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"!!!)
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.
And in the end, even after getting familiar with the idea I ended
up finding it counterproductive due to the above reasons.
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.
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 05, 2002 1:50 AM
>
>
> On Sat, 5 Jan 2002 03:38, Berin Loritsch wrote:
> > A while back, we had big discussions regarding Pool
> implementations. Since
> > we have some that work, little has been said since. After
> using the Pool
> > for a while, it strikes me as odd that our lifestyle interfaces
> ThreadSafe
> > and SingleThreaded are in Framework and the other one is in Excalibur.
>
> In hindsight I am not sure we should have put ThreadSafe or
> SingleThreaded in
> framework.
>
> > However this does bring up the issue of Recyclable Components.
> Components
> > that implement Recyclable have some internal state that they must reset
> > between uses. Currently this is not expressed in Framework. I
> propose a
> > new interface to address this issue:
> >
> > interface Resettable extends SingleThreaded
> > {
> > void reset();
> > }
>
> sounds fine to me.
>
> > By deprecating Poolable and Recyclable, and adding Resettable
> to Framework,
> > the Pool can take advantage of the Resettable interface
> itself. In fact,
> > the Resettable interface is more descriptive of what Recyclable does.
>
> -1 on moving Resettable to framework, I would be more inclined to move
> ThreadSafe/SingleThreaded outside of framework than adding
> anything more in.
>
> > The overall changes I am proposing would either add Resettable to
> > org.apache.avalon.framework.thread or move those interfaces and
> Resettable
> > into org.apache.avalon.framework.lifestyle. It would also deprecate
> > Poolable and Recyclable, and lastly make Pools work with Objects rather
> > than Poolables.
> >
> > The last change is not backwards compatible, and the same
> arguments can be
> > made for its change as the change to PriorityQueue.
>
> -1 on backwards incompatible changes. Just create a whole new
> component and
> deprecate all of the old stuff if you must.
>
> For instance I actually have a component in excalibur.xpool that pools
> resources other than components (No need to implement Poolable or
> any of the
> stuff). This is mainly so I could pool things like datagrams, Chunks
> (basically reusable byte arrays) and other similar objects.
>
> I would prefer you went this path and created a new package for your new
> components.
>
> --
> Cheers,
>
> Pete
>
> *---------------------------------------------------------*
> | Contrary to popular belief, UNIX is user-friendly. It |
> | just happens to be selective on who it makes friendship |
> | with. |
> | - Richard Cook |
> *---------------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
