Polymorphic Rants

Negli ultimi giorni abbiamo inlcuso una tag library (DisplayTag)in alcune JSP; su tomcat tutto bene ma al momento del deploy su JRun abbiamo avuto modo di scoprire altri particolari interessanti. Sostanzialmente l’applicazione non viene deployata con questo stacktrace:
jrun.jsp.compiler.JRunTagLibraryInfo$InvalidTLDElementException:
The tag example on line 244 is not a valid TLD element at jrun.jsp.compiler.JRunTagLibraryInfo$TLDParser.
startElement(JRunTagLibraryInfo.java:613)

Consultando la documentazione di DisplayTag si trova:

[...]this appears to be a JRun fault.

The elements are absolutely valid according to the sun dtd http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd but JRun doesn’t accept them. A bug report has already been submitted to Macromedia hoping they will fix this.

Riassumendo:
- JRun ha un classloader non standard
- JRun parsa in modo sbagliato i tld che rispettano i dtd Sun.

The Daily WTF

just browse it!!

Nei giorni scorsi ho fatto Test Driven Development per lo sviluppo di alcune classi che devono generare un file XML partendo da una serie di informazioni; niente di impossibile, ma sicuramente un contesto adeguato perchè libero da “intromissioni” di database e GUI…..ottima palestra per iniziare a fare TDD!!!

Subito le sensazioni: TDD ti obbliga a pensare “fortemente” orientato agli oggetti. Quelle che nello sviluppo tradizionale sono elucubrazioni, qua sono effettivamente guidate da un feedback molto concreto; mi sono trovato a definire un metodo statico all’interno di un oggetto che non avrei mai fatto con i modi tradizionali, e la scelta è risultatta assolutamente correttissima.

Fare TDD non è per niente facile su codice reale: l’abitudine ti porta a

1. debuggare
2. tracciare il codice (che è sempre una forma di debug)

Con TDD questo non esiste, e la cosa ti mette parecchio in difficoltà quando non riesci a capire perchè certi test non passano; la cosa è moltiplicata dal fatto che con TDD testo i metodi pubblici…ma come faccio a capire se l’errore è su un metodo privato ? (attendo speranzoso risposte…)

L’orientamento agli oggetti che TDD ti da rende veramente più facile ragionare su un design evolutivo: scrivere, rifattorizzare, riscrivere e rifattorizzare ancora è assolutamente naturale con TDD.

Alla fine in circa un giorno e mezzo ho implementato le classi necessarie con i relativi test (una decina); sono parecchio contento della qualità ottenuta, devo ovviamente migliorare sulla scrittura dei tet e sul ritmo nel ciclo barra rossa/barra verde/refactor, ma la prima esperienza con codice reale è assolutamente soddisfacente.

Il progetto su cui sto lavorando da ormai sei mesi sta per entare in produzione; l’architettura su cui andremo a lavorare presenta JRun come servlet container…poco male, J2EE è tutto uno standard, se ci spostiamo da Tomcat a JRun che problemi avremo ???

E invece no…la nostra applicazione (WebWork+ DBCP + Log4J come librerie esterne) non ha alcuna intenzione di andare…il problema ??

Dopo un pò di ricerche, trovo questa pagina che che dice:

A few extra things must be done to get Opinio to work on JRun. JRun does not follow the servlet spec regarding classloaders, and its own libraries (in $JRUN/lib/) will be loaded before those in opinio/WEB-INF/lib. If these modifications are not done, one might get errors like: [1]java.lang.NoClassDefFoundError: org/apache/log4j/Layout
at org.apache.commons.logging.impl.Log4jFactory.getInstance(Log4jFactory.java:140)
at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:257)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:390)
at webwork.config.XMLActionConfiguration.(XMLActionConfiguration.java:51)

solamente ?? !!??

Un servlet container a pagamento non segue le specifiche ?
bene, molto bene…e noi come facciamo ad usare librrie esterne ?
ok, le copio in servers/lib e le rendo visibili a tutte le applicazioni…ma a questo punto non ho + il corretto puntamento ai file xml di configurazione (presenti in WEB-INF/classes)!!!!
soluzioni ?
dopo vari giorni di prove e ricerche, abbiamo trovato due soluzioni (entrambi clamorosi workaround):

1. creo un Jar con i file xml di configurazione e metto anche questi in servers/lib
2. esplodo i jar di terze parti e metto package e classi in WEB-INF/classes, lasciando i file XML al loro posto.

perchè le applicazioni di Windows XP (versione italiana)hanno lo shortcut per salvare su MAIUSC+F12 e non su CTRL+S come tutto il mondo ???