> From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > Are they intrinsically big, or are they big because of all the stuff > every instance must hold that could be delegated to the "component > fields" I suggested?
"Component fields". > I think most components fall in that second category. Me too. Basically, poolable components are components with a high cost of initialization. But at the same time, all components in the pool have the same configuration etc. and thus the same initialization parameters. This makes all components in the pool clones - when a component is put back into the pool it must be reset. Thus, all poolable components can be created anew for each use, if we could just take a snapshot of the component just after initialization. The big exception to this is when each component isn't equal - for example, a DB connection pool has each component corresponding to a *different* connection. > Furthermore, pipeline components are stateful because of the > asynchronous nature of SAX, but that state doesn't survive past the > processing of a pipeline: the state is initialized on startDocument() > and trashed on endDocument(). Hence the possibility to change these > components into factories. I'd go for the change-to-factories approach. Less magic, and it is a well-established pattern. /LS
