Флажки JSF 2 и булевые получатели

Я создаю jaxws-клиент на основе webservice. Jaxb будет генерировать булевы, используя java.lang.Boolean вместо примитивного типа. В дополнение к этому, он будет генерировать соглашение об именовании is() для beans.

Однако, если я попытаюсь связать логическое значение (например, isOptional()) с флажком, это вызовет следующее исключение:

Мои навыки google сообщили мне, что jsf отлично работает с:

Однако невозможно обновить beans вручную из-за размера и количества веб-сервисов, так есть ли способ заставить jsf правильно использовать java.lang.Boolean isOptional()? Или я могу каким-то образом определить свойство в файле привязки jaxb во время генерации, которое магически генерирует "getOptional()"?

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

EDIT: я запускаю последний jdk 7, вывод "java -version":

Ответы

Ответ 1

Jaxb будет генерировать булевы, используя java.lang.Boolean вместо примитивного типа. В дополнение к этому, он будет генерировать соглашение об именовании is() для beans.

Использование префикса is getter для java.lang.Boolean было известной крупной ошибкой JAXB. Он был исправлен в версии 2.1.13, который был выпущен в апреле 2010 года уже. Обновляйте свои библиотеки.

См. также эту статью в блоге для некоторого фона.

Большая ошибка API JAXB

_{15 сентября 2006 г.}

Вы должны передать это Солнцу, чтобы вкрутить это. Одно дело писать программное обеспечение, которое не соответствует спецификации, когда документация имеет толщину, как учебник. Возьмем, к примеру, почти все, что создано W3C. Однако, это действительно плохо, когда это ваша собственная спецификация, которой вы не можете следовать, особенно когда это самая известная ее часть. Правильно, Sun пропустила милю по своей собственной спецификации, когда они создали API JAXB 2.0. JAXB 2.0-компилятор (XJC) неправильно использует префикс "is", а не "get" при генерации метода getter для свойства java.lang.Boolean. В то время как спецификация JavaBean заявляет, что методы чтения для примитивных логических элементов могут использовать альтернативный префикс "is", эта гибкость не распространяется на ее булевскую копию-оболочку.
8.3.2 Логические свойства

Кроме того, для булевых свойств мы позволяем методу геттера соответствовать шаблону:
public boolean is();
Этот метод "есть" может быть предоставлен вместо метода "get" или может быть предоставлен в дополнение к методу "get" . В любом случае, если метод "is" присутствует для логического свойства, мы будем использовать метод "is" для чтения значения свойства.

Пример логического свойства может быть:
public boolean isMarsupial();
public void setMarsupial(boolean m);
Учитывая, что JAXB является основой генерации кода, и идея создания фреймворков генерации кода заключается в том, что код должен использоваться как "как есть", а затем не модифицирован, это довольно большой "oops". Хотя этот вопрос был представлен, ответ от Sun "жаль, его слишком поздно".

Это поведение определяется спецификацией, и, к сожалению, слишком поздно для спецификации теперь менять.

С точки зрения пользовательского опыта, благодаря авто-боксу, я не думаю, что это будет реальной проблемой для людей. Проблема в том, что вы используете Introspector и не хватает свойства? Слишком поздно? Не настоящий вопрос? Это БРОКЕН. ПОЧИНИ ЭТО! Мне также не нравится наивное утверждение о том, что это, вероятно, не повлияет на рамки. Ум, да, это будет, учитывая, что другие проекты действительно соответствуют спецификации (спящий режим, spring, myfaces и т.д.).

ОБНОВЛЕНИЕ: Стево Славян сообщил мне, что это было зафиксировано в JAXB 2.1.13. Подробнее см. JAXB-131. Да!

JSF/EL здесь не виноват. Он выполняет свою работу надлежащим образом JavaBeans spec.

Ответ 2

Я не уверен, почему последняя и самая большая версия JAXB по-прежнему генерирует неправильный метод, но я, наконец, исправил ее, добавив "-B-enableIntrospection" (согласно http://jaxb.java.net/2.2.4/docs/xjc.html) к вызову wsimport. Это приводит к:

public Boolean getOptional() {
    return optional;
}