BAT per stop Tomcat clean directory e restart servizio

Con questo script è possibile stoppare tomcat ripulire le directory e fare il restart.
E' meglio utilizzare il comando NET START o NET STOP piuttosto che sc in quanto sc è asincrono per cui si rischia vada in errore la cancellazione dei file.
Lo script è il seguente:

    @echo OFF

    set CATALINA_HOME=D:\lavoro\apache-tomcat-7.0.53
    net stop TomcatService
   
    
    

    echo removing work
    rmdir /S /Q "%CATALINA_HOME%\work"
    echo making new work dir
    mkdir "%CATALINA_HOME%\work"
 
    echo removing temp
    rmdir /S /Q "%CATALINA_HOME%\temp"
    echo making new temp dir
    mkdir "%CATALINA_HOME%\temp"
 
    echo removing logs
    rmdir /S /Q "%CATALINA_HOME%\logs"
    echo making new logs dir
    mkdir "%CATALINA_HOME%\logs"
 
    echo starting tomcat service
  
    net start TomcatService

Verificare le porte di WebSPhere

WAS  utilizza porte diverse a seconda dell'accesso da console oppure da http o https.
Per verificare quali sono si può aprire il file

AboutThisProfile.txt che si trova tipicamente in

C:\Program Files\IBM\WebSphere\AppServer\profiles\[PROFILO]\logs

Il file presenta queste informazioni:

Ambiente del server delle applicazioni da creare: Server delle applicazioni
Ubicazione: C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01
Spazio su disco richiesto: 200 Mb
Nome profilo: AppSrv01
Imposta questo profilo come valore predefinito: True
Nome nodo: xxxxxxxx
Nome host: xxxxxxxxxxxx
Abilita sicurezza di gestione (consigliato): True
Porta della console di gestione: 9060
Porta sicura della console di gestione: 9043
Porta di trasporto HTTP: 9080
Porta di trasporto HTTPS: 9443
Porta di avvio: 2809
Porta connettore SOAP: 8880
Esegui il server delle applicazioni come servizio: True
Crea una definizione server Web: False
Impostazioni di ottimizzazione delle prestazioni: Standard

PrimeFaces autoscroll dopo update eventi ajax

Spesso in form molto lunghi, quando si scrolla per la compilazione, l'utilizzo di Ajax può essere fastidioso perchè ad ogni esecuzione del codice poi sul client ci si riposiziona in alto e si perde lo scroll.
In javascript questo problema si risolve utilizzando la seguente sintassi:

document.getElementById("idComponente").scrollIntoView();

Dalla versione 3.2 di Primefaces è stato introdotto il metodo  
  RequestContext.getCurrentInstance().scrollTo

Purtroppo però non mi funzionava (stavo utilizzando la versione 3.5).
Comunque un workaround funzionante è quello di utilizzare sempre l'oggetto org.primefaces.context.RequestContext, inserendo il javascript dentro in questo modo:

 RequestContext.getCurrentInstance().execute("document.getElementById( 'componentId' ).scrollIntoView();");

Si noti che l'id deve essere quello generato dal componente a video, per capirci quello che vediamo col viewsource della pagina.

Java8 iterazione esterna

Esempio iterazione esterna con Java 8.
Supponiamo di avere una lista di oggetti di tipo Persona identificati da alcune proprietà (nome, cognome, età ) ed una proprietà isMaggiorenne che ci filtra le persone con età > 18 anni.
Per avere un conteggio di queste occorrenze prima di Java 8 si operava in questo modo:

int count=0;
  for(Persona p: l){
   if(p.isMaggiorenne()){
    count++;
   }
  }

Questa è la classica iterazione esterna.
Con Java 8 si introduce il concetto di iterazione interna , dove invece di procedere noi all'esecuzione del ciclo for si opera sugli stream inserendo i filtri esplicitamente.
Il caso di esempio precedente si risolve in Java 8 nel seguente modo:

long l= i.getListePersone().stream().filter(person -> person.isMaggiorenne()).count();

Oltre alla maggiore compattezza del codice il vero vantaggio è che l'utilizzo degli stream consente  al compilatore di eseguire lui al meglio le operazioni richieste, magari anche parallelizzando le operazioni se necessario.

Settare JDK su Ireport

Ireport attualmente non funziona se abbiamo installato la JDK 1.8.
La versione che ho provato io è la 4.7.0, non proprio l'ultimissima (siamo attualmente alla 5.5.0), comunque anche su quest'ultima leggo sui forum che ci sono problemi.
Io avevo installato la JDK 1.8 ma comunque ho nel path come prima entry quella della JDK 1.6 per cui ero convinto di girare comunque con la JDK 1.6 (anche la JAVA_HOME punta alla JDK 1.6).
Attenzione quindi, iReport prende la JDK da suoi ragionamenti interni ignorando le opzioni specificate a livello di sistema....

Avevo il seguente messaggio di errore (il file di log di Ireport si trova in Windows  sotto c:\Utenti\nomeutente\.ireport\4.7.0\var\log\messages.log )

java.lang.IllegalStateException: java.lang.IllegalAccessException: Class org.openide.util.WeakListenerImpl$ProxyListener can not access a member of class org.openide.filesystems.$Proxy0 with modifiers "public"

Per risolvere occorre modificare il seguente file ireport.conf che si trova sotto C:\Program Files\Jaspersoft\iReport-4.7.0\etc.

In particolare ho modificato la parte in grassetto

# ${HOME} will be replaced by user home directory according to platform
default_userdir="${HOME}/.${APPNAME}/4.7.0"
default_mac_userdir="${HOME}/Library/Application Support/${APPNAME}/4.7.0"

# options used by the launcher by default, can be overridden by explicit
# command line switches
default_options="--branding ireport -J-Xms256m -J-Xmx512m -J-Dorg.netbeans.ProxyClassLoader.level=1000 -J-XX:MaxPermSize=512m "
# for development purposes you may wish to append: -J-Dnetbeans.logger.console=true -J-ea

# default location of JDK/JRE, can be overridden by using --jdkhome <dir> switch
#
jdkhome="C:/Program Files/Java/jdk1.6.0_45"

# clusters' paths separated by path.separator (semicolon on Windows, colon on Unices)
#extra_clusters=


 

Javascript timer

Un contatore di secondi in Javascript:

<!DOCTYPE html>
<html>
<body>

<p>Script che starta un contatore:</p>

<p id="demo"></p>

<script>
var myVar=setInterval(function(){myTimer()},1000);
var cont=-1;
function myTimer() {
    var d = new Date();
    document.getElementById("demo").innerHTML =cont+myVar+" secondi trascorsi";
    cont=cont+1;
}
</script>

</body>
</html>

Risultato:

Configurazione WAS 8.5 per chiamate HTTPS

Se da una applicazione Web richiamiamo un url di WebSphere e questa Url è in https allora è necessario importare il certificato dentro WebSphere.
Si noti che questo vale sempre, anche se ci si connette a siti trusted (es https://www.google.it).
Mi è capitato infatti che lo stesso codice funzionante su Tomcat 7 andasse in errore su Was 8.5.
L'eccezione in fase di chiamata era la seguente :

Error 500: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: java.security.cert.CertPathValidatorException: The certificate issued by OU=Equifax Secure Certificate Authority, O=Equifax, C=US is not trusted; internal cause is: java.security.cert.CertPathValidatorException: Certificate chaining error 

Per risolvere occorre seguire i passaggi seguenti

1 - Da console WAS 8.5 Sicurezza/Gestione chiavi e certificati SSL

2 - Selezionare keystore e certificati

3 - Cliccare quindi su "Certificati firmatario"

4 - Selezionare NodeDefaultTrustore per accedere alla lista

5 - Selezionare l'opzione "Richiama da porta" e quindi inserire i dati del server, la porta (di solito la 443) e un alias che possiamo definire a piacere per il nome del trustore, quindi cliccare su Richiama Informazioni Firmatario per avere i dettagli del certificato

 Salvando questa configurazione, senza necessità di riavviare WAS 8.5 la chiamata all'url in https funziona correttamente.