Java no convierte cadenas a objetos largos correctamente

Question

Estamos utilizando Spring / Hibernate en un servidor de aplicaciones Websphere para AIX. En mi máquina Windows, el problema no ocurre, solo cuando se ejecuta AIX. Cuando un usuario inicia sesión con un número de cuenta, si prefieren el '0' a su ID de inicio de sesión, la aplicación rechaza el inicio de sesión. En la tabla de DB2, la columna es de tipo numérico, y no debería haber ningún problema al convertir '090 ....' a '90 ... '

¿Alguien más experimenta un problema como este? Ambas máquinas tienen Java v1.5.

Para ser más específico, el flujo es FormView - > LoginValidator - > LoginController

En LoginValidator, el valor de inicio de sesión es nulo con el prefijo 0. Sin el 0, el valor es el que debería ser (Pero de nuevo, esto es solo en el entorno AIX; en 2 entornos Windows está bien). Aquí está el fragmento de código donde el objeto es igual a nulo ...

public class LoginValidator implements Validator  {

    public boolean supports(Class clazz) {
    return Login.class.equals(clazz);
    }

    @SuppressWarnings("all")
    public void validate(Object obj, Errors errors) {
        System.out.println("Inside LoginValidator");
        Login login = (Login) obj;
        //null value
        System.out.println("Before conversion in Validator, store id = " 
              + login.getStoreId()); 
    }
}

También he escrito este breve programa Java para construir un Long a partir de una String y usar el binario java que está empaquetado con WebSphere

public class String2Long {
    public static void main(String[] args){
        String a = "09012179";
        String b = "9012179";

        Long _a = new Long(a);
        Long _b = new Long(b);

        System.out.println(a + " => " + _a); //09012179 => 9012179
        System.out.println(b + " => " + _b); //9012179 => 9012179
        System.out.println("_a.equals(_b) " + _a.equals(_b)); //_a.equals(_b) true
    }
}

SOLUCIÓN

Answer 1

SOLUTION

Un compañero de trabajo investigó algunas actualizaciones de Spring, y aparentemente este error fue correcto en la versión 2.5.3:

  

CustomNumberEditor trata el número con ceros a la izquierda como decimal (se eliminó el soporte octal no deseado mientras se conserva el hexadecimal)

Estábamos usando Spring 2.0.5. Simplemente reemplazamos los frascos con Spring 2.5.4, ¡y funcionó como debería!

Gracias a todos por su ayuda / asistencia. Haremos uso de las pruebas unitarias en el futuro, pero esto resultó ser un error de Spring.

Answer 2

Bueno, hay un montón de cosas pasando allí. Realmente necesita tratar de aislar el problema: resolver qué se envía a la base de datos, qué está viendo Java, etc.

Intente fijarlo en un programa corto pero completo que solo muestre el problema; entonces estará en una posición mucho más sólida para presentar un error o corregir su código.

Answer 3

Rastree el programa siguiendo la ruta de la cadena hasta la base de datos y realice pruebas unitarias para cada método en esa ruta. Y no solo tome la ruta más corta posible aquí, realice múltiples pruebas unitarias con diferentes entradas y salidas esperadas para ver realmente qué salió mal. Suponiendo que no encuentra ningún error, ejecute las mismas pruebas unitarias en la otra computadora y debería poder identificar el error. Desde lo alto de mi cabeza, supongo que puede tener algo que ver con mayúsculas y minúsculas, pero realmente no hay forma de estar seguro.

La próxima vez, use TDD.

Answer 4

No sé mucho acerca de Java, pero esto puede suceder que la cadena se interprete como cadena octal debido a los principales "0".

Probablemente pueda solucionar esto usando Long.parseLong (a, 10).