GlassFish e driver JDBC

Dove mettere i driver JDBC per le applicazioni che girano sotto GlassFish?

$GLASSFISH_HOME/domains/$DOMAIN/lib/ext/

Windows Vista: deframmentazione

Si sa: Winzozz non e' un sistema operativo, e' un virus, che si replica e nel tempo abbatte le performance del tuo nuovo e fiammante pc.
Ai tempi, quando ancora usavo il mio fido Amiga 1200 (cresciuto nel tempo fino a diventare un 68030 + ppc603) si diceva che Amiga andava bene solo per giocare (l'ignoranza accompagna l'umanita da sempre).
Ora posso finalmente dire la stessa cosa: Windows e' solo un insieme di api e librerie per far girare i giochi... perche' quindi sradicarlo completamente dal mio nuovo Core 2 Duo?
E' semplicemente, parafrasando Trip Hawkins, una tassa da pagare per videogiocare.
Quindi, meglio metterlo in quarantena, chiuderlo in una partizione ad hoc, dove non potra' piu' nuocere a nessuno, e lasciare il rimanente spazio dell'hard disk a chi, in questi ultimi anni, se l'e' guadagnato: GNU/Linux Ubuntu.
Per prima cosa, ho bisogno di una bella deframmentazione.
Ho provato ad usare il tool adatto allo scopo incluso in Windows Vista, ma, dopo ore passate davanti ad una barra di avanzamento, senza una minima indicazione di quanto tempo ancora fosse necessario per completare l'operazione, ho deciso di provare Auslogics Disk Defrag, un programma free, che nell'ordine dei minuti ha portato a casa il risultato.

Software Technical Event - Sun

Sun ha un centro di ricerca e sviluppo in Francia... sarebbe proprio da vedere, magari in occasione del seguente evento:
http://fr.sun.com/sunnews/events/2007/nov/grenoble/index.jsp

GlassFish e dintorni: slide/presentazioni

Sul wiki di GlassFish sono raccolte un buon numero di presentazioni, da tenere sempre in considerazione per un'infarinatura delle tecnologie che ruotano intorno all'application server di Sun.

Client side charts - parte II

Le possibilita' per creare qualcosa di accattivante senza ricorrere a Flash (e per me accattivante significa Google Chart API) ci sono tutte:

PlotKit
Plotr
Flot

Devo solo valutare quale sia la libreria' piu' matura che offra la roadmap piu' interessante...

JSP: spazi bianchi e linee vuote

L'output dell'esecuzione di una pagina JSP e' spesso pieno di linee vuote e di spazi inutili... una vera rottura, soprattutto quando e' necessario produrre una pagina XHTML e la dichiarazione XML dev'essere per forza di cose la primissima riga!

Finalmente tutto cio', con JEE 5.0 e le JSP 2.1 e' stato risolto per mezzo di un semplice parametro di configurazione: trimDirectiveWhitespaces.

Per saperne di piu' basta leggere questo articolo.

Client side charts

Soltanto un link, per non perderlo di vista:

css + php + flash + ajax charts

Glassfish 2.0: installazione

La roadmap di Glassfish e' decisamente interessante... Glassfish 3 starta in mezzo secondo!!!

E' ora di iniziare a prendere confidenza con questo promettente (e maturo) application server... installiamo la versione 2 su un bel dev redhat ;)

> mkdir glassfish
> cd glassfish
> java -jar glassfish-installer-v2-b58g.jar
> mv glassfish glassfish-2.0

mhmh e' preconfigurato per ascoltare di default sulle porte 8080 (http), 8181 (https), 4848 (web console), 3700 (corba), 7676 (jms)... ho gia' la 8080 occupata da resin, riassegno le porte a glassfish...

> vi setup.xml
> :1,$s/8080/7070/g
> :1,$s/8181/7171/g
> :1,$s/4848/7878/g
> :1,$s/3700/7700/g
> :1,$s/7676/7600/g
> :wq!

> chmod u+x lib/ant/bin/ant
> lib/ant/bin/ant -f setup.xml

ant mi comunica che e' andato tutto bene:

create.domain:
[exec] Using port 7878 for Admin.
[exec] Using port 7070 for HTTP Instance.
[exec] Using port 7600 for JMS.
[exec] Using port 7700 for IIOP.
[exec] Using port 7171 for HTTP_SSL.
[exec] Using default port 3820 for IIOP_SSL.
[exec] Using default port 3920 for IIOP_MUTUALAUTH.
[exec] Using default port 8686 for JMX_ADMIN.
[exec] Domain being created with profile:developer, as specified by variable AS_ADMIN_PROFILE in configuration file.
[exec] Security Store uses: JKS
[exec] Domain domain1 created.
[exec] Login information relevant to admin user name [admin] for this domain [domain1] stored at [/home/httpd/.asadminpass] successfully.
[exec] Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage this domain.
[delete] Deleting: /store2/sw/as/glassfish/glassfish-2.0/passfile

BUILD SUCCESSFUL
Total time: 18 seconds


posso startare l'as:

> bin/asadmin start-domain domain1

che parte correttamente:

Starting Domain domain1, please wait.
Log redirected to /store2/sw/as/glassfish/glassfish-2.0/domains/domain1/logs/server.log.
Redirecting output to /store2/sw/as/glassfish/glassfish-2.0/domains/domain1/logs/server.log
Domain domain1 is ready to receive client requests. Additional services are being started in background.
Domain [domain1] is running [Sun Java System Application Server 9.1 (build b58g-fcs)] with its configuration and logs at: [/store2/sw/as/glassfish/glassfish-2.0/domains].
Admin Console is available at [http://localhost:7878].
Use the same port [7878] for "asadmin" commands.
User web applications are available at these URLs:
[http://localhost:7070 https://localhost:7171 ].
Following web-contexts are available:
[/web1 /__wstx-services ].
Standard JMX Clients (like JConsole) can connect to JMXServiceURL:
[service:jmx:rmi:///jndi/rmi://XXXXXXXXXXXXXXXXX:8686/jmxrmi] for domain management purposes.
Domain listens on at least following ports for connections:
[7070 7171 7878 7700 3820 3920 8686 ].
Domain does not support application server clusters and other standalone instances.

Apache Resin request dispatch

Per fare in modo che il webserver Apache sappia quali richieste debba servire e quali invece debba passare a Resin, esistono due possibili configurazioni:

1) Resin, tramite il ResinConfigServer, comunica ad Apache quali risorse e' suo compito servire
2) Apache sa esattamente quali risorse deve servire Resin

Io preferisco di gran lunga la seconda :)

<Location "/webapp/jsp/">
CauchoHost localhost 6802
SetHandler caucho-request
</Location>

Resin profiler

Resin dispone di una servlet filter in grado di misurare i tempi di risposta del servlet engine nel servire le richieste HTTP.

E' possibile configurare la servlet filter nel file resin-web.xml (preferibile: essendo una feature di Resin, inserire la configurazione nel file web.xml minerebbe la portabilita' della webapplication su differenti application server) in questo modo:

<!-- resin profiler filter -->

<filter>
<filter-name>resin-profiler-filter</filter-name>
<filter-class>com.caucho.tools.profiler.ProfilerFilter</filter-class>
<init-param>
<param-name>use-query</param-name>
<param-value>false</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>resin-profiler-filter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>

I tempi di risposta misurati dalla servlet filter possono essere visualizzati in un browser, grazie ad una servlet il cui compito e' 'intabellare' i dati, da configurare anch'essa nel file resin-web.xml:

<!-- resin profiler servlet -->

<servlet>
<servlet-name>resin-profiler-servlet</servlet-name>
<servlet-class>com.caucho.tools.profiler.ProfilerServlet</servlet-class>
<init>
<profiler enabled="true" />
</init>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>resin-profiler-servlet</servlet-name>
<url-pattern>/resin-profiler</url-pattern>
</servlet-mapping>

La suddetta servlet, se invocata col parametro in get format=xml, e' in grado di fornire gli stessi dati in formato xml.

E' cosa buona e giusta non permettere a chiunque di vedere i dati raccolti dal 'resin profiler'... una semplice soluzione puo' essere configurare, nel file resin-web.xml, un 'filtro' per l'imitare l'accesso alla servlet 'ProfilerServlet' solo a determinati indirizzi IP:

<security-constraint>
<web-resource-collection>
<url-pattern>/resin-profiler</url-pattern>
</web-resource-collection>
<ip-constraint>
<allow>127.000.000.001/32</allow><!-- localhost -->
<allow>192.168.000.000/16</allow><!-- classe C -->
</ip-constraint>
</security-constraint>

JSF 1.2_04 RI + Tomcat 6.0.10

E' stata dura, ma c'e' l'ho fatta :)
Tutto grazie a questo thread: http://forum.java.sun.com/thread.jspa?threadID=787962&messageID=4487741

In parole povere, per veder funzionare la reference implementation di JavaServerFaces 1.2 con Tomcat 6, e' sufficiente deployare nella directory $CATALINA_HOME/lib (quindi fra le librerie di tomcat) i seguenti jar:

1) jsf-api
2) jsf-impl
3) jstl-1.2

tutte le librerie necessarie sono daunlodabili da questi link:

https://javaserverfaces.dev.java.net
https://maven-repository.dev.java.net/nonav/repository/jstl/jars

Java PermGen system property

In applicazioni server a volte risulta necessario aumentare la ram disponibile per l'area di memoria 'PermGen' a disposizione della jvm; questo'operazione, in grado di risolvere la temuta 'java.lang.OutOfMemoryError: PermGen space', si realizza passando all'interprete java una banale system property.
Ipotizziamo di voler portare a 256 MB la memoria disponibile al solo PermGen:

-XX:MaxPermSize=256m

Resin 3.0.19 Hibernate JPA

Sembrerebbe che la versione 3.0.19 di Resin abbia qualche problema con l'implementazione JPA di Hibernate3: nonostante siano state importate tutte le dipendenze e sia stato configurato il file services.xml per l'utilizzo di Hibernate3 come JPA provider, Resin si ostina ad utilizzare Amber come implementazione di JPA.
La stessa webapplication non presenta il problema sopra riportato ne' su Resin 3.0.22, ne' su Resin 3.1.0.

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>