> From: Peter Donald [mailto:[EMAIL PROTECTED]]
>
> Hi,
>
> On Wed, 5 Jun 2002 11:24, Gregory Steuck wrote:
> > Peter> Can you give me one solid reason why it needs to
> be done at
> > Peter> runtime in 99% of cases? I will grant you that runtime
> > Peter> assembly may be necessary when components looked up are
> > Peter> determined by request data but in other cases?
> >
> > The component in question needs to be:
> >
> > * expensive to construct
> > * single threaded
> > * often used for short periods of time
> >
> > Can anybody name such a component? Something similar to a database
> > server will do ;-)
>
> Sounds like you are not designing with scalability in mind
> ... and thus it
> does'nt scale :)
>
> ie Consider the following example. When connecting to a
> database and you need
> to retrieve resources to access database from a service
> directory (whether
> that be ServiceManager, ComponentManager or JNDI Context
> etc).Should you
>
> a) Store the Connection object in service directory
> b) Store a DataSource in service directory
>
> Obviously most people are going to say (b) because it scales
> well and is
> simple to do. However time and time again I have heard people
> from Cocoon
> advocate an approach like (a) for their components.
I have tried to convince the Cocooners to do something more
along the lines of (b), but it is not an easy proposition
because of the number of people using it.
>
> Due to this we get into discussions such as
> * Component/Service Manager should do pooling (erk!!!!)
The Container needs to take care of that. Many containers do perform
pooling (anybody ever here of EJBs, Servlets, DataSources, etc.?).
We need to make the mechanism invisible to the user though.
> * Component/Service Manager should be more efficient (double erk!!!!)
It really does. Even if it is more efficient to *use* or develop
against. Believe it or not, the indirection I am proposing *saves*
on complexity and helps the new developer comprehend the code more
easily.
Try/Catch/Finally blocks are not friendly to newbies, and you need
a lot of experience to avoid nasty gotchas like catching Exception
before catching ComponentException. Veterans would laugh at the
concept, but I see newbies do it all the time.
> Can't you just create a service like
>
> interface GeneratorFactory
> {
> int getIdFor(String type);
> Generator createGenerator(int id);
> }
>
> and repeat for all performance sensitive operations. It would
> make cocoon sooo
> much faster and it would also mean we wouldn't have to keep making
> compromises in core parts of Avalon for what I consider to be
> bad use cases.
I am trying to accommodate both you and the cocoon people.
my proposal gets rid of the *Selector interface necessity.
However, what you might see more ready for Cocoon is this:
interface Generator
{
XMLSource getSource();
}
with implementations for the different generator types. It is
essentially the same thing, except the GeneratorFactory looks like
it might resolve any type of Generator.
I am trying to get to a place where we can all be happy.
Unfortunately, not everything is like a Phoenix app.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
