Paul Hammant wrote: > > > > > > >For the moment but the long-term strategy would be to move everything to use > >block directly rather than ThreadContext.getThreadPool(). The main reason is > >because that matches how we use it and it would be easier to manage > >performance characteristerics of pool that way. > > > I'm intrigued. You see multiple implementations of threadpool don't you..
Can you make it a simple Component instead of a Block? I want to be able to use the Thread Pooling in places where Blocks can't be compiled/used. For instance, Cocoon has a few locations where it spawns a background thread--that really should be managed by a Thread Pool. Also, in the absence of an *official* Thread Pool implementation, JdbcDatasource and ActiveMonitor spawn their own threads--when they really need to use the Thread Pool. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
