質問

AIX用のWebsphere Application ServerでSpring / Hibernateを使用しています。私のWindowsマシンでは、AIXから実行している場合にのみ問題は発生しません。ユーザーがアカウント番号でログインするときに、ログインIDの前に「0」を付けると、アプリケーションはログインを拒否します。 DB2テーブルでは、列は数値型であり、「090 ....」から「90 ...」への変換に問題はないはずです

このような問題を経験している人はいますか?両方のマシンにJava v1.5があります。

具体的には、フローはFormViewです-> LoginValidator-> LoginController

LoginValidatorでは、loginの値は0のプレフィックスが付いたnullです。0がない場合、値は本来の値になります(ただし、これはAIX環境でのみ有効です。2つのWindows環境では問題ありません)。これは、オブジェクトが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()); 
    }
}

また、文字列からLongを構築し、WebSphereにパッケージ化されているjavaバイナリを使用するためのこの短いJavaプログラムを作成しました

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
    }
}

解決策

役に立ちましたか?

解決 2

ソリューション

同僚がSpringの更新に関するいくつかの調査を行ったところ、このエラーはv。2.5.3で正しかったようです:

  

CustomNumberEditorは、先頭にゼロを付けた数値を10進数として扱います(16進数を保持しながら、不要な8進数のサポートを削除しました)

Spring 2.0.5を使用していました。 jarファイルをSpring 2.5.4に置き換えるだけで、本来の機能を発揮しました!

あなたの助け/支援に感謝します。ユニットテストは将来使用しますが、これはSpringのバグであることが判明しました。

他のヒント

さて、そこには非常に多くのことが起こっています。あなたは本当に問題を切り分けようとする必要があります-データベースに送信されているもの、Javaによって見られているものなどを見つけてください。

問題を示すちょうど短いが完全なプログラムでそれを特定してみてください-そうすれば、バグを報告したりコードを修正したりすることができるようになります。

文字列のパスをデータベースまでたどるプログラムをトレースし、そのパス上のすべてのメソッドについて単体テストを行います。ここで可能な限り最短のルートを取るだけでなく、さまざまな入力と予想される出力を使用して複数のユニットテストを行い、問題の可能性を実際に確認してください。エラーが見つからないと仮定して、他のコンピューターで同じユニットテストを実行すると、バグを特定できるはずです。頭の上から、大文字と小文字の区別に関係があると思いますが、実際に確認する方法はありません。

次回はTDDを使用します。

Javaについてはあまり知りませんが、文字列が先頭の" 0"のために8進数の文字列として解釈される可能性があります。

おそらく、Long.parseLong(a、10)を使用してこれを回避できます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top