Java не преобразует строку в длинный объект должным образом - PullRequest
2 голосов
/ 14 ноября 2008

Мы используем Spring / Hibernate на сервере приложений Websphere для AIX. На моей машине с Windows проблема не возникает - только при запуске из AIX. Когда пользователь входит в систему с номером учетной записи, если он добавляет префикс «0» к своему идентификатору входа, приложение отклоняет вход в систему. В таблице DB2 столбец имеет числовой тип, и не должно возникнуть проблем при преобразовании «090 ....» в «90 ...»

Кто-нибудь еще сталкивался с такой проблемой? Обе машины имеют Java v1.5.

Если быть более точным, поток будет FormView -> LoginValidator -> LoginController

В LoginValidator значение login равно нулю с префиксом 0. Без 0 значение должно быть тем, чем должно быть (но, опять же, это только в среде AIX - в двух средах Windows это нормально). Вот фрагмент кода, в котором объект равен нулю.

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

Я также написал эту короткую Java-программу для создания Long из строки и использования двоичного файла Java, который поставляется вместе с 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
    }
}

РЕШЕНИЕ

Ответы [ 4 ]

3 голосов
/ 15 ноября 2008

РЕШЕНИЕ

Сотрудник провел некоторые исследования обновлений Spring, и, по-видимому, эта ошибка была правильной в версии 2.5.3:

CustomNumberEditor обрабатывает число с ведущими нулями как десятичное число (убрана нежелательная восьмеричная поддержка при сохранении шестнадцатеричного числа)

Мы использовали Spring 2.0.5. Мы просто заменили банки на Spring 2.5.4, и все заработало как надо!

Спасибо всем за вашу помощь / помощь. Мы будем использовать модульные тесты в будущем, но это оказалось ошибкой Spring.

3 голосов
/ 14 ноября 2008

Ну, там происходит очень много всего. Вы действительно должны попытаться изолировать проблему - выяснить, что отправляется в базу данных, что видит Java и т. Д.

Попробуйте закрепить его в короткой, но полной программе, которая просто показывает проблему - тогда вы будете в гораздо более сильном положении, чтобы сообщить об ошибке или исправить свой код.

2 голосов
/ 14 ноября 2008

Трассировка через программу по пути String до базы данных и выполнение модульных тестов для каждого метода на этом пути. И не просто выбирайте кратчайший возможный маршрут, проведите несколько модульных тестов с разными входами и ожидаемыми выходами, чтобы действительно увидеть, что пошло не так. Предполагая, что вы не найдете никаких ошибок, запустите те же модульные тесты на другом компьютере, и вы сможете точно определить ошибку. Наверху головы я бы предположил, что это как-то связано с чувствительностью к регистру, но на самом деле нет уверенности.

В следующий раз используйте TDD.

0 голосов
/ 15 ноября 2008

Я не знаю много о Java, но это может случиться, что строка интерпретируется как восьмеричная строка из-за ведущего "0".

Возможно, вы можете обойти это, используя Long.parseLong (a, 10).

...