Le regole d'oro

Proviamo a scriverle queste famose regole d'oro, che sia la volta buona che vengano lette?

• un metodo di una action non dovrebbe mai superare le 5 linee di codice, se le dovesse superare dovremmo sempre chiederci "sto facendo la cosa giusta?"
• le eccezioni non andrebbero mai gestite dentro le action, ma in maniera dichiarativa (vedi articolo), specialmente quelle relative all'autenticazione ed all'autorizzazione
• le action dovrebbero sempre chiamare il domain e mai interagire direttamente con le factories
• i controlli sintattici andrebbero sempre fatti utilizzando la validazione di Struts
• i controlli semantici andrebbero fatti a livello di BusinessObject
• la valorizzazione di un form o di un bean dovrebbe essere sempre fatta utilizzando il locale preso dalla request

JBoss logging

la configurazione di default della componente log4j di JBoss non è certamente adatta agli ambienti di produzione per diversi motivi: vediamo quali.

Innanzitutto l'appender su file presenta due caratteristiche non adatte ad ambienti ad alto accesso: non è configurato in append ed il livello di logging non è limitato.
Il parametro append, esplicitamente impostato a false, fa si che ogni riavvio dell'application server comporti la completa perdita di tutti i log della giornata (solo della giornata per l'appender è in rotazione giornaliera) e questo, come potete immaginare, può essere un problema grave per la diagnosi di problemi.
In secondo luogo l'assenza del parametro Threshold consente a tutti i tracciamenti che superano il filtro globale di finire all'interno del file di log: questa impostazione potrebbe non essere ottimale se l'applicazione presenta numerosi statement di log a livello DEBUG. Se siamo in questo specifico caso la soluzione più semplice è quella di impostare il parametro menzionato al livello INFO, ma questo ci impedirebbe di raccogliere eventuali preziosi log per la risoluzione di anomalie. Una soluzione più efficace ed efficente è quella di filtrare gli statement che rendono il nostro file di log troppo grosso usando una direttiva del tipo

   <category name="org.jboss.management">
      <priority value="INFO"/>
   </category>

che limita il livello di log di una specifica categoria (o package) ancora prima che questo venga reindirizzato verso il file.

Una ulteriore ottimizzazione possibile sulla dimensione dei file di log è procedere periodicamente alla loro compressione che può portare enormi benefici vista la tipologia di dati in essi contenuta. Un semplice script eseguito giornalmente da cron può essere una valida soluzione:

find /tmp/log/ -regextype posix-basic -regex '.*server.log..*[0-9]' -exec gzip '{}' +

Transport dt_socket failed to initialize, rc = 509.

Vi è mai capitato ti ritrovarvi il messaggio d'errore in oggetto mentre lanciate jboss in debug da eclipse?? bhè finalmente ho capito di cosa si tratta!

Il problema si verifica quando sulla stessa macchina coesistono più installazioni (ovviamente di versioni diverse ) della j2sdk. Sembra che la jvm non riesca a capire quale versione prendere delle librerie dt_socket e sh_mem. Tra le diverse opinioni trovate in giro per il web l'unica che ho sperimentato essere funzionante è la seguente:

Copiate le dll:
- dt_shmem.dll
- dt_socket.dll

situate nella cartella ${JAVA_HOME}/jre/bin
nella cartella:

${JAVA_HOME}/bin

Naturalmente il tutto vale solo su s.o. windows...
su linux il discorso è analogo basta fare in modo che librerie stiano nel path rispetto al comando javaw ...

Hibernate IDBAG

Consiglio a tutti di dare un'occhiata al seguente link: extending_xdoclet_hibernate_module

Alcuni problemi trovati in passato vi torneranno più chiari...

Differenza Internet Explorer e Firefox nei DIV - Struts e CSS

Differenza Internet Explorer e Firefox nei DIV

Ho notato una differenza di gestione nei tag html <div> tra i due celebri browsers web. In pratica, inserendo qualcosa in un div, ad esempio una tabella, Firefox considera la dimensione del div quanto il 100% dello schermo, mentre Internet Explorer ridimensiona il div a seconda dell’oggetto che contiene.
La differenza tangibile a livello grafico è che se si cerca di centrare una tabella o un altro oggetto in IE, esso se ne andrà comunque a sinistra, poiché la centratura è effettuata all’interno del div, mentre il div stesso occupa solo una porzione di schermo. Nessun problema su Firefox.
Soluzione:
Semplicemente dotare il tag div in questione di una entry nel CSS in modo tale da impostargli la larghezza al 100% dello schermo (width: 100%;)

Utilizzo CSS in tag Struts.

Potrebbe sembrare una banalità ai più, ma inizialmente non ci avevo fatto caso. Avevo la necessità di impostare una dimensione esatta per i combo box, che in Struts si indicano con *html:select property="nomecollection"*. Ho subito risolto inserendo una entry nel CSS:


.comboBox {
font-family: Geneva, Arial, Helvetica, sans-serif;
font-size: small;
line-height: normal;
font-weight: normal;
height: auto;
width: 160px;
cursor: text;
border-top: groove #B0B0B0;
border-right: groove #B0B0B0;
border-bottom: ridge #808080;
border-left: ridge #808080;
}
Modificando nella pagina JSP il tag:

*html:select property=”nomecollection” styleClass="comboBox"*

Infine vorrei segnalare l’utilità della proprietà z-index sempre nell’ambito CSS per indicare il fattore di profondità degli oggetti. Questo è utile in caso di oggetti sovrapposti. Un valore più alto porta l’oggetto in primo piano e viceversa.

Utilizzo del tag di struts <html:cancel>

Per utilizzare in una jsp il tag <html:cancel> possiamo considerare il seguente esempio:

<html:cancel titleKey="operation.cancel.title" styleClass="button">
<bean:message key="operation.cancel"/> </html:cancel >

Nel file struts.xml, nella action corrispondente scriveremo:

<action path="..." name="..."
scope="..." type="" parameter="..." input="...">
<forward name="..." path="..."
redirect="true" />
<forward name="..." path="..." />
<forward name="cancel" path="/index.jsp" redirect="true" />
</action>


Dal file di struts viene richiamato in automatico il metodo cancel della classe Action:

protected String cancel(ActionForm form, HttpServletRequest request, HttpServletResponse response, ActionMapping mapping) throws Exception {

super.reset(form, request, mapping);
return "cancel";
}

Ancora lezioni di stile

Ho individuato un modello praticamente perfetto per gestire lo stile dei form in maniera molto flessibile ed anche molto stilosa.

Cominciamo con lo sfruttare completamente l'HTML che mette a disposizione tre tag che vengono utilizzati pochissimo ma che sono molto preziosi per la definizione dei form cioè <fieldset>, <label> e <legend>.

Il tag fieldset è utilissimo per raggruppare blocchi di campi fra di loro sia per individuare raggruppamenti differenti all'interno di uno stesso modulo, sia semplicemente per separare i campi di input dai pulsanti che rappresentano i comandi.

Il tag label invece identifica l'etichetta associata ad un campo di input ed è molto utile per specificare che un certo testo non è messo lì tanto per riempire la pagina. Questo tag specifica un attributo for grazie al quale si può identificare il tag per cui è etichetta così da realizzare una vera e propria associazione.

Infine il tag legend fornisce una descrizione generica che può essere associata ad un fieldset per definirne una descrizione.

Già nella loro definizione di base, rappresentata di seguito, rendono i form molto più leggibili.

Connection parameters

host


port


username


password

Utilizzando i fogli di stile si possono creare dei form molto molto carini come ottimamente descritto in questo sito ed esemplificato in questa immagine.



A questo punto non rimane che aggiungere una descrizione del campo, magari attraverso un help a pop-up come descritto in questa pagina, ed eventualmente aggiungere una evidenziazione del campo attualmente in edit con una combinazione di stili e JavaScript come mostrato in questo link.