Resin 3: war deploy

Resin, come altri servlet engine, permette il deploy di un war, che il container si occupa di esplodere nella directory corrispondente.
Dal passaggio alla release 3.0.18 ho pero' notato che come comportamento di default, Resin, nel caso in cui il file web.xml fosse gia' presente (tipicamente nel rilascio di una nuova versione dell'applicativo in sostituzione della vecchia) preferiva mantenere la vecchia versione del file e non sovrascriverla con la nuova presente nel pacchetto war.
Ho tagliato la testa al toro aggiungendo queste poche righe di configurazione (che non sono standard JavaEE, ma sono proprietarie di Resin) nel file resin-web.xml (ma nulla vieta che possa essere fatta la stessa cosa intervenendo sul file resin.conf):

<web-app-deploy path="webapps">
<expand-cleanup-fileset>
<include>*</include>
</expand-cleanup-fileset>
</web-app-deploy>

Ho assegnato all'attributo path dell'element web-app-deploy il valore 'webapps' (che e', nella configurazione di default, il nome della directory contenente i war e gli applicativi esplosi), mentre ho detto, per mezzo di <expand-cleanup-fileset><include>*</include></expand-cleanup-fileset>, a Resin, di eliminare qualsiasi file preesistente al momento dell'esplosione del war.

XFire 1.2 + Spring 2.0

Sto incontrando qualche difficolta' nel far funzionare XFire 1.2 RC con Spring 2.0 RC3...

Fino ad ora ho sempre esposto dei webservices con XFire dichiarando i servizi da esporre nel file 'META-INF/xfire/services.xml': XFire utilizza XBean per la propria configurazione, il quale si occupa di configurare il framework Spring al nostro posto.

Col passaggio alla release 2.0 di Spring, utilizzando la release 2.4 di xbean-spring questo non e' piu' possibile: sembrerebbe che il problema sia stato gia' indirizzato, e potrebbe essere risolto con la release 2.5 di XBean.

Qui e' possibile trovare l'aggiornamento di XBean compatibile con la versione 2 di Spring:
http://geronimo.apache.org/xbean/download.html

Un'altra soluzione possibile e' provare a configurare direttamente XFire per mezzo di Spring, senza l'ausilio di XBean:
http://xfire.codehaus.org/Spring%2C+XBean%2C+Servlets+and+more

AROS

AROS e' un sistema operativo opensource compatibile con AmigaOS 3.1.
E' disponibile per diverse piattaforme hardware, tra le quali x86 e PPC ed e' in grado di girare nativamente sulle piattaforme supportate oppure all'interno di un sistema operativo in grado di ospitarlo come processo (per esempio GNU/Linux).