Java non converte correttamente la stringa in oggetto lungo

Question

Stiamo usando Spring / Hibernate su un Websphere Application Server per AIX. Sul mio computer Windows, il problema non si verifica, solo quando si esegue AIX. Quando un utente accede con un numero di account, se antepone '0' al proprio ID di accesso, l'applicazione rifiuta l'accesso. Nella tabella DB2, la colonna è di tipo numerico e non ci dovrebbero essere problemi a convertire "090 ...." in "90 ..."

Qualcun altro ha riscontrato un problema come questo? Entrambe le macchine hanno Java v1.5.

Per essere più specifici, il flusso è FormView - > LoginValidator - > LoginController

In LoginValidator, il valore di login è nullo con lo 0 prefissato. Senza lo 0, il valore è quello che dovrebbe essere (ma, di nuovo, questo è solo sull'ambiente AIX - su 2 ambienti Windows va bene). Ecco lo snippet di codice in cui l'oggetto è uguale a 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()); 
    }
}

Ho anche scritto questo breve programma Java per costruire un Long from a String e usare il binario java che è impacchettato 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
    }
}

SOLUZIONE

Answer 1

SOLUTION

Un collega ha fatto delle ricerche sugli aggiornamenti di primavera e apparentemente questo errore era corretto in v. 2.5.3:

  

CustomNumberEditor considera il numero con zeri iniziali come decimale (rimosso supporto ottale indesiderato preservando esadecimale)

Stavamo usando la primavera 2.0.5. Abbiamo semplicemente sostituito i vasetti con Spring 2.5.4 e ha funzionato come avrebbe dovuto!

Grazie a tutti per il vostro aiuto / assistenza. Faremo uso dei test unitari in futuro, ma questo si è appena rivelato essere un bug di primavera.

Answer 2

Beh, ci sono un sacco di cose da fare lì. Devi davvero provare a isolare il problema: capire cosa viene inviato al database, cosa viene visto da Java ecc.

Prova a fissarlo in un programma breve ma completo che solo mostra il problema, quindi sarai in una posizione molto più forte per archiviare un bug o correggere il tuo codice.

Answer 3

Traccia attraverso il programma seguendo il percorso della stringa fino al database e fai unit test per ogni singolo metodo su quel percorso. E non limitarti a percorrere qui il percorso più breve possibile, fai più test unitari con input e output previsti diversi per vedere davvero cosa è andato storto. Supponendo di non riscontrare errori, eseguire gli stessi test unitari sull'altro computer e si dovrebbe essere in grado di individuare il bug. Dalla parte superiore della mia testa presumo che potrebbe avere qualcosa a che fare con la distinzione tra maiuscole e minuscole, ma non c'è davvero modo di esserne sicuro.

La prossima volta usa TDD.

Answer 4

Non so molto di Java, ma ciò potrebbe accadere se la stringa viene interpretata come stringa ottale a causa del principale "quot 0".

Probabilmente puoi aggirare questo problema usando Long.parseLong (a, 10).