2008-11-14 7 views
1

Nous utilisons Spring/Hibernate sur un serveur d'applications Websphere pour AIX. Sur mon ordinateur Windows, le problème ne se produit pas - uniquement lors de l'exécution d'AIX. Lorsqu'un utilisateur se connecte avec un numéro de compte, s'il préfixe le '0' à son ID de connexion, l'application rejette le login. Dans la table DB2, la colonne est de type numérique et il ne devrait pas y avoir de problème à convertir '090 ....' en '90 ... 'Java Non Conversion chaîne à long objet correctement

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

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

En LoginValidator, la valeur de connexion est nul avec le préfixée 0. Sans 0, la valeur est ce qu'elle devrait être (mais encore une fois, ce n'est que sur l'environnement AIX - sur 2 environnements Windows ça va bien). Voici l'extrait de code où l'objet est égal à zéro ..

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 aussi écrit ce programme court Java pour la construction d'un long d'une chaîne, et en utilisant le binaire java qui est livré 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

+0

Se pourrait-il que le code convertissant en un Long voit le 0 initial et pense qu'il est octal? –

+0

C'est possible, mais cette plateforme est-elle dépendante? Ce problème ne se produirait-il pas aussi sur une machine Windows? –

+0

Cela ne devrait certainement pas être le problème. Mais essayez d'isoler le code défaillant et ensuite le reproduire par lui-même - une application de console courte est bonne pour cela (ou un test unitaire, bien sûr). –

Répondre

2

SOLUTION

Un collègue a fait des recherches sur les mises à jour de printemps, et apparemment cette erreur a eu raison v. 2.5.3:

CustomNumberEditor traite nombre avec des zéros, le nombre décimal (retiré du support octal indésirables tout en préservant hex)

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

Merci à tous pour votre aide/assistance. Nous utiliserons les tests unitaires dans le futur, mais cela s'est avéré être un bug de printemps.

3

Eh bien, il y a énormément de choses qui se passent là-bas. Essayez d'isoler le problème - élaborez ce qui est envoyé à la base de données, ce qui est vu par Java, etc.

Essayez de l'épingler dans un programme court mais complet qui juste montre le problème - alors vous serez dans une position beaucoup plus forte pour déposer un bug ou réparer votre code.

+0

Cela doit être quelque chose quand Spring est en train de construire l'objet Command, puisque c'est la première chose qu'il fait avant d'aller au Validator. Je vais faire un SystemOut à l'intérieur des setters et voir ce qui se passe là-bas, merci. –

+0

Plutôt que d'utiliser System.out, je vous suggère d'utiliser un débogueur. Même si vous ne pouvez pas l'utiliser sur la boîte AIX, vous devriez être capable de voir ce qui est en train de faire la conversion sur votre boîte de dev - ce qui devrait vous permettre d'isoler le code défectueux. –

2

Trace à travers le programme suivant le chemin de la chaîne sur toute la base de données et à faire des tests unitaires pour chaque méthode unique sur cette voie. Et ne prenez pas simplement la route la plus courte possible ici, faites des tests unitaires multiples avec des entrées différentes et des sorties attendues pour vraiment voir ce qui s'est mal passé. En supposant que vous ne trouvez aucune erreur, exécutez les mêmes tests unitaires sur l'autre ordinateur et vous devriez être en mesure de localiser le bogue. Du haut de ma tête, je suppose que cela peut avoir quelque chose à voir avec la sensibilité à la casse, mais il n'y a vraiment aucun moyen d'être sûr.

La prochaine fois, utilisez TDD.

0

Je ne sais pas beaucoup sur Java, mais cela pourrait se produire la chaîne est interprétée comme une chaîne octal à cause du premier « 0 ».

Vous pouvez probablement contourner cela en utilisant Long.parseLong (a, 10).

+0

Une valeur de chaîne ne doit pas subir d'interprétation octale. Mais Java ne le fait pas de toute façon. new Long (a) appelle Long.parseLong (a, 10) si vous regardez le code JDK –

+0

Je n'ai pas regardé le code JDK, mais j'ai remarqué le standard disant quelque chose comme ça. Je pensais juste que IBM pourrait avoir une implémentation différente qui contient un bug. L'appel explicite de Long.parseLong (a, 10) testerait cette hypothèse. –

-1

Je ne sais pas pourquoi il se comporte différemment sur différents systèmes. Il y a beaucoup de langages dérivés de C, un nombre commençant par un zéro est considéré comme étant en octal, pas en décimal. Encore une fois, il devrait se comporter de la même manière sur toutes les plateformes, mais vous pouvez essayer le conseil de Hans en spécifiant la base 10 dans la méthode parseLong.

+0

new Long (String) appelle Long.parseLong (String, 10) si vous regardez le code, il ne devrait donc pas y avoir de différence. –

Questions connexes