Error “svn export failed” en WebSVN al hacer un tarball

Pero que complicado es esto… y desesperante. Lograr tener todo perfecto y sin ni una mancha 😛

Logo de WebSVNHoy vamos a luchar contra un “bug” (no se si se puede decir que sea culpa del script) de WebSVN en su rama 2.3.x. Si no conoces este software/script/web, es una pequeña página web que usa PHP, que permite acceder a un servidor Subversion desde una página web muy amigable. Este programa tiene la característica de hacer un zip/tar con el código fuente y bajarlo desde esta web… salvo si pones acentos en algún fichero. Entonces tendremos un bonito error que pondrá algo como:

svn export failed [...]

En ese momento piensas: “Seguro que es una chorrada de configuración de la web”. Mal, compañero, mal. Siguiendo una lógica deductiva busque si era un error de WebSVN, luego de Subversion, luego de Apache, luego de PHP y luego del sistema operativo. Obviamente, y como ocurre en estos casos, era un error en conjunto.

La causa, básicamente, es que Apache siempre arranca con las “locale” asignas a “C”, y obviamente, WebSVN lanza Subversion con dichas “locale” lo que hace que no sepa interpretar los caracteres acentuados y eñes (que están en UTF-8).

¿Como arreglarlo?, así de fácil o de complicado (como quieras verlo):

// Fichero websvn/include/setup.php
//
// Busca la línea 329 mas o menos, donde habrá algo del tipo:
setlocale(LC_ALL, '');
// Cambialo a:
setlocale(LC_ALL, 'es_ES.UTF-8');
// Añade esta línea
putenv('LC_ALL=es_ES.UTF-8');

Si no codificación de caracteres no es la misma, pues pon la que tenga tu equipo (ejecuta un “locale” en la consola).

Hecho.

Referencias:

Please follow and like us:

Cuando Double.MaxValue, no es Double.MaxValue

Creo que es uno de los primeros post que voy a escribir por absoluta desesperación. Y el título lo dice todo.

Estamos desarrollando una aplicación en mi empresa, donde usamos un librería “open source” construida de manera intachable. Bien estructurada, con sus clases, con sus interfaces, y todo en NET 2.0.

Ahora viene lo bueno, dentro de la librería, hay un:

public const double Missing = Double.MaxValue;

Esta línea, parece encarnar el mal, y tiene el número #630 dentro del sistema de bugtracking del proyecto (a partir de ahora el número del mal). En ciertos equipos (si, en ciertos, sin diferenciación mayor que ser otro equipo), provoca que el programa se salga (mejor dicho: explote), sin generar ninguna excepción (lo que implica un error por debajo incluso del NET) y sin dejar ningún registro de error. En cambio, si ponemos:

Si hacemos una asignación quitando el alias:

public const double Missing = 1.7976931348623157E+308;

Tenemos otro crash silencioso al ejecutar el programa. Incluso rebajando el exponente, tenemos el mismo fallo. Pero esperen, que viene lo mejor:

public const double Missing = 999999999999999999;

Entonces, todo el felicidad, los pájaros cantan y las nubes se levantan… No falla.

¿¿¿Porqué???. De verdad que no lo entiendo, y los oscuros mundos del NET me tienen frito.

Pues no termino de entender el porque. Puedo conjeturar que viene por la representación que le da .NET, no es representable por algún nivel más bajo de la máquina, o algún redondeo que implique un overflow. Pero la verdad que no he encontrado nada por la red, y menos aun por los foros de la librería. Pueden ser muchos factores, y me estaré dejando muchos sin tener en cuenta, pero desde luego ahora mismo estoy falto de ideas.

Please follow and like us:

Geoserver y las extensiones “ImageIO-ext” no se llevan bien con Tomcat (>= 6.0.24)

Parece que tenemos un problema, Houston. Y uno gordo.

Muchas de las personas que utilizamos Geoserver como servidor de mapas, nos hemos decidido por la combinación Geoserver+Tomcat, ya que parece una forma “ordenada” y “optimizada” de implantar un servidor de mapas.

Pero todo tiene problemas.

Si hemos instalado las extensiones “ImageIO-ext” para obtener la posibilidad de usar muchos más formatos de fuentes de cartografía en nuestro servidor, y por casualidad hemos actualizado a una versión de Tomcat por encima de la 6.0.24 (inclusive) nos encontramos que al intentar usar un formato de los que nos da soporte las extensiones “ImageIO-ext”, encontramos este fantástico error:

Caused by: java.lang.IllegalArgumentException: Incorrect input type!
       at javax.imageio.ImageReader.setInput(ImageReader.java:290)
       at it.geosolutions.imageio.gdalframework.GDALImageReader.setInput(GDALImageReader.java:838)

¿Yuhu?. Bueno, al menos, es un error reconocido por la gente de Geoserver y ahora mismo esta trabajando en ello, aunque no creo que tengan una solución próxima, ya que el problema esta en la extensión, no en el servidor Geoserver. La extensión tiene un problema de “leak” de memoria en ciertas condiciones, y las nuevas versiones de Tomcat tiene un nuevo mecanismo que detecta esto fallos que pueden peligrar el buen funcionamiento del servidor y hacen que no permita el registro de la extensión en el sistema (et voilà, ya no tenemos acceso a la extensión).

Aunque haya algún “workaround” a la vista, como deshabilitar dicho mecanismo de protección anti-fugas de memoria en el servidor Tomcat. Aunque esperemos que no quede mucho para que lo solucionen de una manera mas “fina”.

Referencias:

Please follow and like us:

Curioso error en WordPress, el “redirect” de “post-new.php”

Intrigado me hayo.

He tenido un error muy raro, pero mucho, con WordPress en su versión 2.7.1, que uso para administrar este blog.

Según trataba de escribir un nuevo post, la página cargaba sin problema y podia trabajar, PERO cuando se me recargaba (por el tema del guardado automático), la página se quedaba reducido a unos botones (del TinyMCE creo), y nada mas.

blog_error2

Buscando he visto que hay mucha gente con el mismo error, incluso se han tomado la molestia de poner capturas del error que he puesto un poco mas arriba. Durante al menos una hora me ha fallado. Y de golpe, todo vuelve a funcionar… ¿Sabeis el miedo que he pasado?, madre mia, tener que meter mano al WordPress… Solo de pensarlo me pongo a temblar.

Please follow and like us: