Mobi ready score

.mobi e' un dominio pensato per siti realizzati per cellulari e palmari... in mancanza, durante lo sviluppo, di una serie di device per il test del sito su cui si lavora, esiste uno strumento web adatto allo scopo, in grado inoltre di validare il sito e suggerire le correzioni del caso (spesso relative a difetti non riscontrabili con la sola navigazione sul semplice device mobile):

http://mr.dev.mobi

Java Reverse Proxy

Ho trovato, e sto utilizzando con grande soddisfazione all'interno di un web container, un reverse proxy open source scritto in java:

http://j2ep.sourceforge.net

jEasy Extensible Proxy (j2ep) dipende da alcune librerie opensource:

commons-beanutils
commons-codec
commons-digester
commons-httpclient
commons-logging

Nel mio progetto mi e' stato utile per proxare delle richieste HTTP le cui response venivano chesciate dalla Cache Servlet Filter di OpenSymphonyCache.

Configurare j2p e' davvero semplice...

Come prima cosa e' necessario scrivere un file di configurazione xml con l'elenco degli host che andranno proxati, ed il path (dal context, escluso, in poi) che fa scattare la chiamata HTTP proxata; questo file lo chiameremo data.xml:

<?xml version="1.0" encoding="UTF-8"?>
<config>
<server className="net.sf.j2ep.servers.BaseServer" domainName="osnews.com">
<rule className="net.sf.j2ep.rules.DirectoryRule" directory="/feed" />
</server>
</config>

In questo caso l'host da proxare e' osnews.com, l'url che si desidera proxare e' http://osnews.com/files/recent.xml, e la chiamata al reverse proxy sara' questa:
http://myhost/mywebapp/feed/files/recent.xml.

Il reverse proxy viene configurato con una Servlet Filter nel web.xml (specificando il path del file di configurazione e l'url-pattern sul quale il filter deve scattare) in questo modo:

<filter>
<filter-name>ProxyFilter</filter-name>
<filter-class>net.sf.j2ep.ProxyFilter</filter-class>
<init-param>
<param-name>dataUrl</param-name>
<param-value>/WEB-INF/cfg/data.xml</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>ProxyFilter</filter-name>
<url-pattern>/feed/*</url-pattern>
</filter-mapping>

Resin e Jdk Logging

Resin permette di configurare l'output ottenuto dalle api java.util.logging.* nel file di configurazione resin-web.xml:

<resin:set var="logpath" value="~/logs/" />
<resin:set var="logfile" value="${logpath}${app.name}.log" />
<resin:set var="tmstamp" value="[%Y/%m/%d %H:%M:%S.%s]" />

<log name="${app.name}" level="info" path="${logfile}" timestamp="${tmstamp}" size="100mb" format=" ${fmt.sprintf('%-7s %-35s %s',log.level,log.loggerName,log.message)}">
<logger name="net.sf.j2ep" level="fine" />
<logger name="com.opensymphony.oscache" level="info" />
</log>

IE ed il content type application/xhtml+xml

Microsoft Internet Exploder, anche nella nuova e fiammante versione 7, non e' ancora in grado di gestire il content type application/xhtml+xml.
Nella realizzazione di un sito web per il mobile (.mobi) fruibile anche da web con un normale browser, mi sono scontrato con questo problema.
Una semplice soluzione e' stata configurare il web server Apache affinche' servisse, nel caso in cui il client non fosse stato in grado di gestire il suddetto content type, delle pagine con estensione .html, automaticamente servite da Apache con contet type text/html:

RewriteEngine on
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml
RewriteRule (.*)\.xhtml$ $1\.html [L]

Google Blogger Dashboard Widget

Questo e' un post al solo fine di testare il blogging con il widget per Mac OS X di Google:
http://www.apple.com/downloads/dashboard/blogs_forums/googleblogger.html

resin-web.xml

Il file resin-web.xml contiene direttive e configurazioni custom del servlet engine Resin, relative alla Web Application associata.
La sua presenza e' facoltativa, ma caldamente consigliata, in quanto permette di non 'sporcare' il file di configurazione standard j2ee 'web.xml' con delle configurazioni ad hoc per Resin (comportamento che mina la portabilita' delle web application java fra web container di produttori differenti).
Il file, se presente, si trova nella directory WEB-INF, esattamente come il file web.xml, e come root del documento presenta il seguente tag:

<web-app xmlns="http://caucho.com/ns/resin" xmlns:resin="http://caucho.com/ns/resin/core"></web-app>

HttpClient (Jakarta Commons)

Nel caso in cui sia necessario che la libraria di Jakarta 'HttpClient' si colleghi ad un web server passando per un proxy http, questo link puo' risultare utile:

HttpClient FAQ

Resin 3 e la system property 'javax.servlet.context.tempdir'

In un web container JavaEE la system property 'javax.servlet.context.tempdir' identifica il path della directory temporanea dell'applicazione web.
Di default Resin 3 crea la directory 'tmp' nella directory WEB-INF della document root della webapp.
Nel caso in cui questo comportamento non sia quello voluto, e' possibile riconfigurare il path della directory 'tmp' inserendo nel file di configurazione della webapp 'resin-web.xml':

<temp-dir>~/.my_temp_directory</temp-dir>

vi ed il fileformat

vi (vim) e' praticamente sempre a disposizione su ogni server linux...
tra le altre cose, mi piace utilizzarlo per cambiare il formato dei file, da dos a unix (e viceversa):


(esc) :set fileformat=unix

(esc) :set fileformat=dos

Resin 3: compilare mod_caucho

E' verissimo che Resin funziona alla grande come http server, ma in un tipico ambiente di produzione la configurazione ideale risulta sempre essere Apache + Resin, dove il primo si preoccupa di servire il contenuto statico e di 'proxare' le chiamate che verranno risolte dinamicamente da Resin, mentre il secondo funge da servlet engine / application server.
Il componente che permette suddetta comunicazione tra Apache e Resin e' mod_caucho; e' necessario ricompilare i sorgenti distribuiti con Resin, ed e' consigliato ricompilare cercando di sfruttare al meglio la configurazione hardware disponibile per l'esecuzione del software.
Personalmente ho a disposizione una macchina Linux (Suse 9.0 enterprise edition) con 4 CPU Xeon MP 3GHZ, e, seguendo i consigli del gentoo-wiki e dell'help di configure (configure --help) ho deciso di compilare i sorgenti in questo modo:
./configure --prefix=resin_dir --enable-linux-smp --with-apache=apache_dir --with-java-home=java_dir CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer"
make
make install

resin_dir e' la directory nella quale saranno scritti i file necessari per l'esecuzione di Resin: sara' quindi la directory contenente l'intero servlet engine (escluse ovviamente le applicazioni che ci gireranno sopra)
apache_dir e' la directory contenente il web server apache: mod_caucho sara' copiato nella directory apache_dir/modules (si chiamera' mod_caucho.so)
java_dir e' la directory contenente la jdk (coincide con la variabile d'ambiente JAVA_HOME)

Suggerisco di cancellare la directory di lavoro di resin (quella contenente i sorgenti per la compilazione di mod_caucho) ad ogni ricompilazione... ho impiegato un po' di tempo per capire che lo script non copiava mod_caucho nella directory 'modules' di apache proprio perche' 'aveva memoria' delle compilazioni precedenti :)

tramonto_germania_02

tramonto_germania_02, originally uploaded by diuis.

vediamo un po' come funziona il post da flickr su blogger ;)

Ubuntu: Oracle Express Edition Debian repository

Installare il database Oracle 10g XE su una distribuzione linux derivata da debian, com'e' ubuntu, non e' mai stato cosi' facile...
Tutto quello che si deve fare, e' aggiornare il file /etc/apt/sources.list con la seguente entry:

deb http://oss.oracle.com/debian unstable main non-free

tutto il resto lo fa synaptic ;)

Resin 3: JMX remote monitoring

Utilizzando Java 5 (l'implementazione di Sun) abilitare il monitoring remoto di Resin e della java virtual machine e' estremamente semplice.
E' sufficiente settare tre system property java.
Ipotizziamo di volere in ascolto l'agent JMX sulla porta 9999:
com.sun.management.jmxremote.port=9999
com.sun.management.jmxremote.ssl=false
com.sun.management.jmxremote.authenticate=false
E' possibile passare le system property all'interprete java modificando il file di startup di Resin 'httpd.sh'; ecco un esempio:

# Extra arguments to Java. If you're passing arguments to the JVM, you'll
# need to use -Jxxx. For example, args="-J-ms48m". You can modify
# the pid file with args="-pid server-a.pid"
#
args="-Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

Per una panoramica delle system property disponibili: http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html

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).