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.
Due to this we get into discussions such as
* Component/Service Manager should do pooling (erk!!!!)
* Component/Service Manager should be more efficient (double erk!!!!)
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.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
