Diario de Programación

Llevaba un tiempo viendo cómo prolifera en los sitios web el botón google +1 y quise ponerlo en mi sitio. Buscando cómo ponerlo encontraba cosas que no me acababan de hacer gracia. Hoy he buscado un poco más en serio, he encontrado cómo ponerlo, por supuesto, en el sitio oficial 

Así que ya está, este blog, la chuwiki y el sitio principal tienen todos su botoncito. Ahora a ver qué pasa.

ACTUALIZACIÓN. También he puesto hoy el botón de "twitear", pero me da la impresión de que no va muy bien. Pinchando en el número de "twits", te va a la página de twiter y te muestra los "twits" correspondientes. Pues bien, en el momento de mirar esto, uno de los posts dice 3 twits y pinchando, twiter te muestra sólo dos twits y uno de ellos no tiene nada que ver con el tema. Me recuerda al viejo chiste que dice "Los cuatro contienentes del mundo son tres, Europa y del otro no me acuerdo".

El botón de twiter se saca de aquí http://twitter.com/about/resources/tweetbutton

Hace tiempo que tengo google analytics en mis sitios web. Antes lo miraba con frecuencia, vigilaba las visitas a ver si subían o bajaban, jugaba a ver si había visitantes de países/ciudades exóticas, etc, etc. Pero también hace mucho tiempo que dejé de mirarlo, llega un momento que aburre y si hay muchas o pocas visitas no es más que un dato curioso que no me preocupa en exceso.

Pero ayer se me ocurrió entrar…. y he visto que han cambiado la interfaz que han puesto una cosa que se llama "tiempo real beta". Otra curiosidad más. Muestra en tiempo real las visitas que hay en tu sitio. Unos gráficos con tiempo en el eje X se van desplazando en tiempo real e indicando el número de visitas, un listado de páginas que están siendo vistas y que van cambiando, un mapa en el que ves de dónde vienen los visitantes que también cambia … en fin, curioso

En el vídeo, sobre el minuto 1:15

Me ha tocado abrir conexiones desde código java contra  un servidor https que requiere certificado de cliente. Me he puesto a ello y he aprendido algunas cosas.

Cuando hacemos un cliente java contra un servidor https, java verifica que el certificado que presenta ese servidor es válido. Por ello, si no los tenemos, necesitamos obtener dichos certificados y meterlos en un almacén de certificados que luego le diremos a java que es el almacén de certificados en los que confiamos. Una forma de obtener el certificado es visitar la página con el navegador y pinchar el el candadito que sale junto a la URL. Ahí podemos ver los datos del certificado y guardarlo en un fichero.

Con la herramienta keytool que viene con java podemos meter esos certificados en un fichero único, de nombre genérico "KeyStore". De hecho, el fichero por defecto que crea/usa esta herramienta keytool suele ser $HOME/.keystore. La herramienta keytool nos pedirá una clave cuando cree el fichero para protegerlo y nos pedirá la misma clave cada vez que queramos ver, añadir o borrar certificados de ese fichero. El formato de este fichero se conoce como "JKS" y es propio de java.

El certificado de cliente habitualmente nos lo darán como un fichero, protegido por una clave y su formato suele ser "PKCS12", este es un formato estándar entendido por la mayoría de las aplicaciones no java. Su extensión suele ser .p12

Pues bien, en java tenemos dos opciones para indicar cual es nuestro KeyStore y cual es nuestro certificado de cliente. Una es por medio de propiedades de sistema. Podemos arrancar nuestro código java con propiedades de este estilo

java -Djavax.net.ssl.trustStore=c:/usuario/.keystore ….

y necesitamos hasta 6 de estas propiedades: fichero, clave del fichero y formato del fichero, para el KeyStore y para el certificado del cliente.

Y la otra opción es codificarlo en java directamente, usando clases como SSLContext, TrustStoreFactory, etc, etc. Algo más complejo, pero que nos dará más versatilidad si queremos abrir varias conexiones con juegos de certificados distintos.

Cómo no, todo esto con más detalle en la chuwiki.

Cosas de ver la serie "Navy, investigación criminal"

Si eres capaz de hacer un blog de wordpress que con unas pocas entradas sea capaz de ganar con google adsense 50$ o más diarios, puedes ofertar para esto http://www.freelancer.com/projects/Website-Design-Internet-Marketing/Adsense-site-generating-day.1274180.html ….. o hacértelo para tí mismo. Incluso, ya puestos, hacer tres o cuatro blogs de esos y retirarte.

Hay gente que no sabe lo que pide.

Estoy haciendo un cliente de Web Service con CXF que luego ira en una página web, de forma que un usuario a través de la página pueda consultar los web services. Y ha surgido un pequeño incordio.

Cojo el wsdl y con la herramienta wsdl2java de CXF genero las clases correspondientes al ciente, todo bien. Hago mi software y todo maravilloso, en local, incluso desplegado en mi propio Tomcat, todo va de perlas.

Lo subo al servidor real….. y error. No encuentra los wsdl. Efectivamente, wsdl2java genera el código del cliente y pone en ese código java la ubicación del wsdl. Luego, cuando usas el cliente, el código java de CXF busca no sé para qué ese wsdl y si no lo encuentra, da error y no funciona nada más.

Yo, en mi ignorancia, pensé que ese wsdl no servía para nada una vez generado el código java, así que no lo incluí como parte de mi proyecto ni en el war. Bueno, la solución parece sencilla, basta meterlo en el war y modifiar las clases de cliente generadas por CXF para que lo busquen dentro del webapp en algún sitio. Pues no, no es tan sencillo. Desgraciadamente el código java dentro de un war tiene muy dificil, si no imposible, saber cual es el directorio en el que está la aplicación web. El directorio por defecto suele ser el del ejecutable tomcat y no el de la aplicación web, por lo que una de las soluciones más socorrida en poner los ficheros que necesitas en el classpath, bien dentro de un jar, bien en el directorio WEB-INF/classes. Pero CXF no entiende de una URL que empiece por "classpath:…."

Por internet buscas y sí, hay cosas, pero normalmente suelen ser si usas spring y en los ficheros de XML de configuración de Spring pones cosas y tal. No es el caso, sólo uso Tomcat.

Total, que muy a mi pesar y por no perder el tiempo, opté por poner los wsdl en un directorio fijo y conocido en el servidor y acceder a ellos con path absoluto. En fin, un asquito y una cosa que se me queda en la lista de tareas para revisar "algún día".

ACTUALIZACIÓN: serhii se ha cargado el problema (lo ha solucionado y ya no es un problema), ver comentario número 7. Está claro que algunos debemos dedicarnos a otra cosa  Muchas gracias, serhii.