Другой вопрос был назван дубликатом этого:
В C ++ почему результат cout << x
отличается от значения, которое показывает отладчик для x
?
x
в вопросе - это переменная float
.
Одним из примеров может быть
float x = 9.9F;
Отладчик показывает 9.89999962
, вывод работы cout
- 9.9
.
Ответ оказывается, что точность cout
по умолчанию для float
равна 6, поэтому она округляется до шести десятичных цифры
См. здесь для справки
Существует три основные причины.
FacesServlet
не вызывается. FacesServlet
mapping . URL-адрес ссылки (URL-адрес, который вы видите в адресной строке браузера) должен соответствовать <url-pattern>
файла FacesServlet
, как определено в web.xml
чтобы все работы JSF выполнялись. FacesServlet
- это тот, который отвечает за разбор файла XHTML, сбор представленных значений формы, выполнение преобразования / проверки, обновление моделей, вызывание действий и создание выходных данных HTML. Если вы не вызываете FacesServlet
по URL-адресу, то все, что вы получили (и увидите через rightclick, View Source в браузере), действительно является исходным исходным кодом XHTML.
Если <url-pattern>
, например, *.jsf
, ссылка должна указывать на /register.jsf
, а не на /register.xhtml
. Если это, например, /faces/*
, как и у вас, ссылка должна указывать на /faces/register.xhtml
, а не на /register.xhtml
. Один из способов избежать этой путаницы - просто изменить <url-pattern>
с /faces/*
на *.xhtml
. Таким образом, нижестоящее является идеальным отображением:
<servlet>
<servlet-name>facesServlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>facesServlet</servlet-name>
<url-pattern>*.xhtml</url-pattern>
</servlet-mapping>
Если вы по какой-то причине не можете поменять <url-pattern>
на *.xhtml
, то вы, вероятно, также хотели бы, чтобы конечные пользователи не могли напрямую обращаться к источнику XHTML кодировать файлы по URL-адресу. В этом случае вы можете добавить <security-constraint>
в <url-pattern>
в *.xhtml
с пустым <auth-constraint>
в web.xml
, который предотвращает это:
<security-constraint>
<display-name>Restrict direct access to XHTML files</display-name>
<web-resource-collection>
<web-resource-name>XHTML files</web-resource-name>
<url-pattern>*.xhtml</url-pattern>
</web-resource-collection>
<auth-constraint />
</security-constraint>
Предстоящий JSF 2.3 решит все из вышеперечисленного, автоматически регистрируя FacesServlet
в шаблоне URL-адреса *.xhtml
во время запуска webapp.
. С введением JSF 2.2 еще одна вероятная причина заключается в том, что пространства имен XML не соответствуют версии JSF. xmlns.jcp.org
, как показано ниже, является новым с JSF 2.2 и не работает в старых версиях JSF. Символы почти такие же, как если бы FacesServlet
не вызывался.
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://xmlns.jcp.org/jsf/core"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
Если вы не можете перейти на JSF 2.2, вам нужно вместо этого использовать старые пространства имен java.sun.com
XML:
<html lang="en"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
. Еще одна вероятная причина заключается в том, что несколько реализаций JSF были загружены вашим webapp, конфликтуя и разлагая друг друга. Например, когда ваш путь к классу среды выполнения Webapp загрязнен несколькими различными версиями JSF-библиотек или в конкретной комбинации Mojarra 2.x + Tomcat 8.x, когда в файле web.xml
веб-приложения есть ненужная запись ConfigureListener
, вызывающая ее загрузку дважды.
<!-- You MUST remove this one from web.xml! -->
<!-- This is actually a workaround for buggy GlassFish3 and Jetty servers. -->
<!-- When leaving this in and you're targeting Tomcat, you'll run into trouble. -->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
При использовании Maven убедитесь, что вы правильно определяете зависимости и понимаете области зависимостей. Важно: не связывайте зависимости в webapp, если они уже предоставлены целевым сервером.
JSF имеет очень крутую кривую обучения для тех, кто не знаком с базовыми HTTP , HTML и сервлетами . В Интернете много ресурсов низкого качества. Пожалуйста, игнорируйте фрагменты скриншотов кода, поддерживаемые любителями, в основном ориентированные на доход от рекламы, а не на обучение, такие как розы, учебник, javabeat и т. Д. Они легко узнаваемы, нарушая рекламные ссылки / баннеры. Также, пожалуйста, игнорируйте ресурсы, связанные с юрским JSF 1.x. Они легко узнаваемы с помощью JSP-файлов вместо файлов XHTML. JSP как технология просмотра устарела с тех пор, как JSF 2.0 уже в 2009 году.
Чтобы начать правильно, начните с нашей вики-страницы JSF и закажите авторитетную книгу .