lunedì 12 gennaio 2015

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.



venerdì 9 gennaio 2015

JAX-WS generare WSDL con xsd interni al WSDL

Di default JAX-WS genera l'xsd in un file esterno che poi è referenziato all'interno della sezione types del WSDL generato.
Questa opzione è sicuramente più corretta e rende migliore la lettura del WSDL ma può capitare di volere l'opzione opposta, ossia un WSDL contenente anche gli xsd.
A quanto ho visto qui fino alla versione 2.1 di JAX-WS non era possibile avere questo risultato (nb. la versione 2.1 è quella utilizzata di default da JAVA 1.6).
Dalla jax-ws 2.2 è finalmente possibile con il comando wsgen utilizzando l'opzione inlineSchemas in questo modo

wsgen -Xendorsed -verbose -inlineSchemas   -keep -cp .  it.myclass.MyService -wsdl
 

Tuttavia non sono riuscito a trovare un modo di avere lo stesso risultato deployando il web service su un Application Server.
Anche usando JAX.WS. versione 2.2 non trovo via codice un modo di forzare la generazione del servizio con xsd esterno.

mercoledì 7 gennaio 2015

Internalizzazione con Struts 1.3

Con la vecchia versione di Struts per realizzare l'internazionalizzazione occorre:

1) definire nello struts-config.xml l'elemento message-resources
2) definire un package con i file di properties, tenendo conto che il parameter impostato al punto 1 dovrà puntare al nome del file di properties senza estensione nè localizzazione
3) caricare in sessione nella variabile org.apache.struts.Globals.LOCALE_KEY il locale prescelto

Esempio

definisco un package denominato org.common.i18

con dentro 3 files:
  • messages.properties;
  • messages_en.properties;
  • messages_it.properties
Ogni file ha una proprietà soltanto

welcome.message=Benvenuto (DEF) per il messages.properties
welcome.message=Benvenuto (EN)  per il messages_en.properties
welcome.message=Benvenuto (IT) per il messages_it.properties

Nello struts config definiamo il seguente elemento:


<message-resources key="localeBundle" parameter="org.common.i18.messages">
</message-resources>

La key serve ad individuare univocamente il bundle e quindi consente di definirne più di uno.

Sulla prima action chiamata dall'applicazione si setta il locale in questo modo:


request.getSession().setAttribute(Globals.LOCALE_KEY, request.getLocale());


Nella jsp occorre importare la taglib di struts


<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean"%> 


Per accedere alla proprietà è sufficiente quindi scrivere:


<bean:message key="welcome.message" bundle="localeBundle" />