cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Migration report from Excalibur Event to RunnableManager
Date Tue, 09 Nov 2004 13:19:02 GMT
On Mon, 8 Nov 2004, Giacomo Pati wrote:

> -
> 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.
> 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 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 -
Orixo, the XML business alliance -

View raw message