On Mon, 2 Apr 2001, Craig R. McClanahan wrote:
>
>
> On Mon, 2 Apr 2001 [EMAIL PROTECTED] wrote:
>
> >
> > The keyword here is "standard": if this proposal is for creating a thread
> > pool standard, I'm -1 on it ( for many reasons ). Just creating some
> > interfaces doesn't make it a "standard".
> >
>
> According to the guidelines, it's not a problem to have different
> implementations of possibly overlapping functionality -- so the "standard"
> being created by these interfaces only belong to implementations that
> choose to use it.
Which is likely to be org.apache.commons.pools. If someone wants to create
an implementation using those interfaces probably he'll place it in this
package.
> You are welcome to propose a different approach.
My intention is to refactor the pool/thread pool from tomcat and check it
into sandbox. I hope Peter ( or someone else ) will do the same with the
pools from Avalon, and maybe other projects.
And I hope that all 3-4 pools will evolve to use a common set of
patterns - at wich point we can all agree on a "common" interface ( based
on what is common, of course ).
Even if this doesn't happen, projects may define their own interfaces
and adapters ( like tomcat.Pool defining what tomcat needs from a pool,
and adapters for each pool that needs to be pluged in - similar with the
way other components are plugged in - loggers, connectors, etc ).
Having 2 sets of interfaces is likely to result in complex code and
confusion. Having simpler code ( i.e. a JavaBean-like component with all
the setters for config and the get/borrow, put/return methods ) will be
easier to understand and use. ( IMHO ).
But as I said, I have no objection to the use of interfaces - as long as
it's clear those are not intended as a "standard", but as an
implementation mechanism.
Costin
