On Mon, 8 Nov 2004, Giacomo Pati wrote:
- org.apache.excalibur.store.impl.StoreJanitorImpl This is a core component but because it is outside the scope of Cocoon (lives inthe Excalibur project) I have not migrating it so far. A possible solutions might be to subclass it and overwrite the start method to use the daemon thread pool from the RunnableManager to runn it. => THIS CLASS IS NOT MIGRATED SO FAR BUT SUGGESTIONS ARE WELCOME
I haven't found any other classes using their own Thread instances so far but as we have A LOT OF other jars in our libs there might well be others.
I'll start backporting it to the 2.1.x baranch now.
Backporting is finished.
I've deeply looked at the org.apache.excalibur.store.impl.StoreJanitorImpl. The only way to have it use the RunnableManger is by copying the source :-( because that class isn't made for subclassing. I have one ready just to have me see how it could be implemented. To make the class subclassable we have to open up a bunch of getters/setter and overwrite the start and run method. But this is more or less having it copied.
An other approach would be to refactor the memory management logic into its own method and have the run method call it in its loop body (current impl.). That way subclassing would still overwrite the start and run method but the hole memory management logic will be hidden in its own protected method.
Please, give me some oppinions on how to proceed. Take into account that if we refactor the excalibur-store package we need to release that right together (or one day before) the cocoon 2.1.6 release if we want to have a StoreJanitor impl. that uses the RunnableManager (I've never released any of the Avalon/Excalibur packages, thus don't know how long it will take). Also remember that the Store is core to Cocoon and IMO the core should use the abilities of core components like the RunnableManager.
I know many of you don't see why this has any importance nor why that should happen. Most of us run Cocoon in Jetty or Tomcat. But there are also users with BWL and WAS which run Cocoon there in. Recently a commercial app servers vendor has begun to "sandbox" (via RACF!) the deployed servlets and has inhibited thread creation (IIRC the J2EE spec says "your app components may not spawn their own threads". By the single-class-for thread-creation approache used by the RunnableManager we can point them to where to relax the sandboxing to make Cocoon run again. I have evangelized people to use Cocoon as many of aou have as well. Now some of them need to migrate onto the app server release mentioned above out of strategic directions in their companies and of course they expect some support/help/suggestions.
-- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
