java.lang.RuntimeException Nicht finden FacesContext
Ich weiß nicht, wie es weiter geht, aber ich bekomme immer "java.lang.RuntimeException: Cannot find FacesContext" für meine neue JSF-1.2 web-Anwendung. Ich bin sicher, es ist nur eine Konfiguration, die ich nicht finden kann.
Die Ausnahme tritt mit dem ersten f:
oder h:
tag. Bereits mit den wichtigen <f:view>
am Anfang.
Meine index.jsp
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<f:view>
<html>
<head>
<title>MyWebsite</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">
</head>
<body>
<div>MyContent</div>
</body>
</html>
</f:view>
Meine web.xml
sieht wie folgt aus:
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.jsp</param-value>
</context-param>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>*.jsf</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>720</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
Und dann habe ich auch eine faces-config.xml
das sollte Referenz myBean ich will danach in die Körper von der Seite:
<?xml version='1.0' encoding='UTF-8'?>
<faces-config version="1.2"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<application>
<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
</application>
<managed-bean>
<managed-bean-name>myClassName</managed-bean-name>
<managed-bean-class>
com.company.className
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</faces-config>
Was vermisse ich hier?
InformationsquelleAutor FiveO | 2013-05-03
Du musst angemeldet sein, um einen Kommentar abzugeben.
Damit die JSF -
<f:xxx>
und<h:xxx>
tags beschweren sich, dassFacesContext
kann nicht gefunden werden. DieFacesServlet
ist verantwortlich für die Erstellung der Gesichter Kontext. Das faces-servlet wird aufgerufen, wenn die Anforderungs-URL entspricht dem URL-Muster, die in Ihrem speziellen Fall*.jsf
. Also, wenn Sie öffnen Sie dieindex.jsp
alshttp://localhost:8080/context/index.jsp
oder sind die unter Berufung auf die<welcome-file>
Einstellung, dann sind Sie nicht die Anrufung des faces-servlet und Sie würde in der Tat erhalten diese Ausnahme.Müssen Sie öffnen Sie die
index.jsp
alshttp://localhost:8080/context/index.jsf
oder um die welcome Datei-Eintrag zuindex.jsf
um richtig zu berufen, die faces-servlet, so dass Sie es erstellen können, die Gesichter Kontext, der erforderlich ist, durch die JSF-Komponenten erklärt werden in der JSP-Seite.Beachten Sie jedoch, dass nur die Festsetzung der Willkommens-Datei ist nicht ausreichend in diesem JSF-1.x + Tomcat-Umgebung. Sie müssen auch liefern eine physikalisch vorhandene, aber völlig leer
index.jsf
- Datei neben derindex.jsp
- Datei in das webcontent, um zu täuschen, Tomcatindex.jsf
wirklich existiert, als Willkommens-Datei. Es wäre etwas anderes zeigen, eine 404-Fehler, da es überprüft die physische Präsenz der welcome Datei vorher.Siehe auch:
Unabhängigen zu dem konkreten problem, ich Frage mich, warum bist du mit JSP, wenn Sie haben anscheinend installiert Facelets-1.x und registrierte seinen Blick handler. Facelets ist weit superior JSP.
.jsf
suffix und dann einfach umleiten auf die .jsp-Seiten. Naja ich weiß noch nicht wirklich auf die Idee kommen JSF-wie auch immer - ich bin verwendet, um HTML und möchte Sie weiter zu verwenden, die syntax - wie ich eine 100% ige Kontrolle über den code des Benutzers zu bekommen. Also werde ich weiterhin mit .jsp und vergessen jsf.stackoverflow.com/a/4424775 kurz: JSF-beseitigt die Notwendigkeit zu schreiben, die HTML - /CSS - /JS selbst (Sie müssen nur lernen, welche HTML-Ausgabe der JSF-Komponenten generiert, so dass Sie leicht wählen Sie die richtige eine) und es beseitigt auch die Notwendigkeit, manuell zu sammeln, übermittelte Werte, konvertieren, validieren, und Sie als bean-Eigenschaften und idenfity und ruft die Methode Aktion. Sie letztendlich mit einer JSP-Datei als "view" und eine javabean, die als "Modell". In anderen Worten, Sie am Ende mit weniger code.
Ich muss allerdings zugeben, dass JSP ist eine schreckliche view-Technologie und macht JSF 1.x unnötig schmerzhaft. Siehe auch stackoverflow.com/a/3646940
Auch weniger code für die Entwickler, aber die browser haben, um generierten code. Also ist diese "less-code" bedeutet, dass weniger Kontrolle, 3rd-party-Abhängigkeiten und am Ende produzieren frustration im Falle von Problemen oder Anpassungen. Aber vielen Dank für die Kommentare - vielleicht sollte ich wirklich schauen Sie in der erweiterten version wie 2.X+.
Der generierte code ist HTML. Browser haben sich zu "behandeln", die Sie verwenden, JSF oder nicht. Insgesamt, jeder Rahmen wird Ihnen "weniger Steuern", sei es bei JSF, EJB, JPA, etc. Jedoch, die meisten der Zeit, Sie geben Ihnen einen Weg, Dinge zu tun, auf "manuell". Mit JSF kann man immer schreiben, Reine HTML/CSS/JS, oder erstellen Sie Ihre eigenen benutzerdefinierten tags/Komponenten. Sie brauchen keine 3rd-party-Abhängigkeiten, einfach nur pure Java EE laufen auf eine vollständige Java Application Server wie Glassfish, JBoss oder WebSphere AS. IMO, frustration ist, dass das Rad neu zu erfinden, immer und immer wieder, anstatt der Fokussierung auf den business-code.
InformationsquelleAutor BalusC