Java ne convertit pas correctement la chaîne en objet long

Question

Nous utilisons Spring / Hibernate sur un serveur d'applications Websphere pour AIX. Sur mon ordinateur Windows, le problème ne se produit pas - uniquement lorsque vous utilisez AIX. Lorsqu'un utilisateur se connecte avec un numéro de compte, s'il ajoute le préfixe "0" à son identifiant de connexion, l'application refuse la connexion. Dans la table DB2, la colonne est de type numérique et la conversion de '090 ....' à '90 ... 'ne devrait pas poser de problème.

Quelqu'un d'autre a-t-il rencontré un problème comme celui-ci? Les deux machines ont Java v1.5.

Pour être plus précis, le flux est FormView - > LoginValidator - > LoginController

Dans LoginValidator, la valeur de login est null avec le préfixe 0. Sans le 0, la valeur est ce qu'elle devrait être (mais encore une fois, cela ne concerne que l'environnement AIX - sur 2 environnements Windows, c'est correct). Voici l'extrait de code où l'objet est égal à null.

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()); 
    }
}

J'ai également écrit ce court programme Java pour la construction d'un long à partir d'une chaîne et pour l'utilisation du binaire java fourni avec 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
    }
}

SOLUTION

Answer 1

SOLUTION

Un collègue a fait des recherches sur les mises à jour de Spring. Apparemment, cette erreur était correcte dans la v. 2.5.3:

  

CustomNumberEditor traite les nombres avec zéros à gauche comme des nombres décimaux (suppression de la prise en charge octale non désirée tout en préservant l'hex)

Nous utilisions Spring 2.0.5. Nous avons simplement remplacé les pots par Spring 2.5.4 et tout a fonctionné comme il se doit!

Merci à tous pour votre aide / assistance. Nous utiliserons les tests unitaires à l’avenir, mais il s’est avéré qu’il s’agissait d’un bogue de Spring.

Answer 2

Eh bien, il se passe énormément de choses. Vous devez vraiment essayer d’isoler le problème - déterminez ce qui est envoyé à la base de données, ce qui est vu par Java, etc.

Essayez de le cerner dans un programme court mais complet qui montre seulement le problème - vous serez alors dans une position beaucoup plus solide pour signaler un bogue ou corriger votre code.

Answer 3

Parcourez le programme en suivant le chemin de la chaîne jusqu'à la base de données et effectuez des tests unitaires pour chaque méthode de ce chemin. Et ne prenez pas simplement le chemin le plus court possible ici, effectuez des tests unitaires multiples avec différentes entrées et sorties attendues pour vraiment voir ce qui a mal tourné. En supposant que vous ne trouviez aucune erreur, exécutez les mêmes tests unitaires sur l’autre ordinateur et vous devriez pouvoir identifier le bogue. Je suppose que cela a peut-être quelque chose à voir avec la sensibilité à la casse, mais il n’ya vraiment aucun moyen d’en être sûr.

La prochaine fois, utilisez TDD.

Answer 4

Je ne connais pas grand chose à Java, mais cela peut arriver, la chaîne est interprétée comme une chaîne octale en raison du "0" précédent.

Vous pouvez probablement contourner ce problème en utilisant Long.parseLong (a, 10).