Блог

Главная - Вопросы по программированию - Проверка компонента GWT не возвращает всех нарушений ограничений в режиме компиляции

Проверка компонента GWT не возвращает всех нарушений ограничений в режиме компиляции

#gwt #bean-validation #objectify

#gwt #компонент-проверка #объективировать

Вопрос:

Я сталкиваюсь с другим поведением проверки компонента на стороне клиента при запуске в режиме разработки gwt, чем в режиме компиляции. Я пытался отлаживать и устранять эту проблему в течение нескольких часов (на самом деле дней), но, хотя в дальнейшем все еще не нашел основную причину и в настоящее время застрял. Отсюда и моя просьба о помощи.

В целом я следовал предлагаемому здесь подходу http://www.gwtproject.org/doc/latest/DevGuideValidation.html и еще больше меня вдохновили различные статьи и вопросы по StackOverlow. Итак, я прошу пользователя ввести объект на клиенте. Затем я проверяю это на стороне клиента с помощью вызова средства проверки, созданного фабрикой проверки.

Проблема, с которой я сталкиваюсь, заключается в том, что когда проверяется более одного ограничения (т. Е. пользователь вводит 2 или более «ошибок»), средство проверки не (всегда) возвращает все нарушения ограничений при запуске в режиме компиляции, в то время как оно возвращает их все при запуске в режиме разработки gwt.

Объект, который я пытаюсь проверить, относится к классу EnvyMonUser 

 @Entity
public class EnvyMonUser implements Serializable, Obj<EnvyMonUser> {
private static final long serialVersionUID = 3L;
private static final String EMAIL_PATTERN = "^[_A-Za-z0-9-\ ] (\.[_A-Za-z0-9-] )*@"
          "[A-Za-z0-9-] (\.[A-Za-z0-9] )*(\.[A-Za-z]{2,})$";

@Id
private Long id;

@NotNull(message = "company must be selected")
@Index
private Key<Company> companyKey;

@Index
private String googleUserId;
@NotNull(message = "email address must be set")
@Pattern(regexp = EMAIL_PATTERN, message = "invalid email address")
@Index
private String email;
@NotNull(message = "name must be set")
@Size(min = 3, message = "must have a name of minimal 3 characters")
@Index
private String nickName;

@NotNull(message = "location must be selected")
@Index
private Key<SampleLocation> sampleLocationKey;

@NotNull(message = "result must be set")
@Index
private Long value;

...

Где Company и SampleLocation — это два других класса. (Аннотации @Entity, @Index, @Id и ключ класса имеют Objectify. Я использую один и тот же класс сущностей на стороне клиента и сервера (gae). )

Как только пользователь ввел объект EnvyMonUser, я проверяю его с помощью средства проверки, т. Е.

 Validator validator = Validation.buildDefaultValidatorFactory().getValidator();

...

EnvyMonUser obj = getView().getEditorDriver().flush();

Set<ConstraintViolation<O>> validate = validator.validate(obj);

где находится моя фабрика проверки

 public final class AppValidatorFactory extends AbstractGwtValidatorFactory {
@GwtValidation(value = { MonitorType.class, Measurement.class,
        ProgramMeasurement.class, EnvyMonUser.class, Company.class,
        SampleLocation.class })
public interface GwtValidator extends Validator {
}

@Override
public AbstractGwtValidator createValidator() {
    return GWT.create(GwtValidator.class);
}
}

Я делаю что-то не так?

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

Я уже пробовал несколько маршрутов, но пока безуспешно. Например, в какой-то момент я подумал, что это вызвано использованием objectify. Однако, когда я удаляю sampleLocationKey участника, он отлично работает для участника companyKey. Я также попытался удалить атрибуты objectify, но это также, похоже, не имеет значения.

Интересная вещь, которую я заметил (случайно), заключается в том, что когда я удаляю (комментирую) некоторые элементы из методов hashCode и equals , поведение меняется. Не уверен, почему это так. Возможно, это как-то связано с тем, как реализован генератор валидатора.

У кого-нибудь есть какие-либо подсказки?

Также приветствуется указатель в правильном направлении. Кто-нибудь, например, знает, где я могу найти сгенерированный валидатор. Или исходные коды генератора валидатора?

Некоторые версии библиотек, которые я использую:

  • gwt 2.6.0
  • hibernate-validator-4.1.0.Final.jar
  • hibernate-validator-4.1.0.Final-sources.jar
  • slf4j-api-1.6.1.jar
  • slf4j-log4j12-1.6.1.jar
  • log4j-1.2.16.jar
  • objectify 4.0.1

Комментарии:

1. Вопреки тому, что я сказал выше, это, похоже, связано с использованием Key класса objectify. По какой-то причине, если задействован equals метод com.googlecode.objectify.Key compareTo of com.google.appengine.api.datastore (который на практике является, в конечном итоге, методом), результирующая проверка работает некорректно. Может ли это быть из-за переходного процесса, appIdNamespace который используется в compareToInternal ? К сожалению, решения пока нет. Поэтому предложения по-прежнему более чем приветствуются!

2. Обнаружена возможная ошибка в, com.google.gwt.validation.client.impl.ConstraintViolationImpl которая могла быть причиной этого: groups.google.com/forum /#!topic/Google-Web-Toolkit/xRVGnMWfttc

Ответ №1:

Оказывается, проблема была не в моем коде, а в ошибке в исходных текстах gwt для com.google.gwt.validation.client.impl.ConstraintViolationImpl . Смотрите https://groups.google.com/forum /#!topic/Google-Web-Toolkit/xRVGnMWfttc для получения полного описания проблемы и решения.

Ответ №2:

У меня была такая же проблема. Проверки работали нормально в режиме разработки, и все сообщения об ошибках отображались в пользовательском интерфейсе, но в режиме prod мы могли видеть только одно сообщение об ошибке за один раз. Позже, когда я отлаживал и обнаружил, что мой DTO реализовал equals и метод hashcode, и это то, что вызывает эту проблему. На момент удаления этих двух реализаций из моего DTO после этого все работало нормально.

Я использую GWT 2.6.1.