Java Anfang zum Deploy Descriptor web.xml im Detail

Tr3x

Lieutenant
Registriert
Feb. 2007
Beiträge
650
Hallo,

ich einarbeite mich gerade in die Welt von JSF2.2. Habe hier zu auch ein Buch "Java Server Faces 2.2" von Michael Kurz.
Aktuell hänge ich stark bei dem Verständnis der web.xml.

Das einzigste was für mich kein Rätsel ist der Bereich welcome-page. Der Rest ist für mich totales Rätsel. Jetzt bin ich die ganze Zeit auf der Suche nach Quellen die mal die web.xml ausführlich erläutert.

Mich würde interessieren was das tag servlet und servlet mapping genau macht und wie man diese konfiguriert und entsprechend erweitert. Könnte mir da jemand etwas behilflichsein?

Code:
<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
  http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
 
    <display-name>ShareCon</display-name>
    <welcome-file-list>
        <welcome-file>home.xhtml</welcome-file>
    </welcome-file-list>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>
    
</web-app>
 
Oder man lässt den alten Kram gleich hinter sich und arbeitet ohne web.xml. Ich hab das letzte mal vor über 2 Jahren eine web.xml gesehen :D
 
Die web.xml dient (in diesem einfachen Fall) nur dazu, dass dein Servlet-Container das "javax.faces.webapp.FacesServlet" lädt und alle *.xhtml Anfragen an das FacesServlet zur Bearbeitung weiterleitet. Das geschieht über den vergebenen Servlet-Name "Faces Servlet", der stimmt bei "servlet" und "servlet-mapping" überein. Das Welcome-File ist die Datei, die aufgerufen wird, wenn keine Datei angegeben wurde - quasi der Default.

Ich kenne das Buch nicht. Da stellt sich natürlich erst mal die Frage, ob du direkt mit Tomcat oder Jetty arbeitest, oder auf JavaEE, Spring oder ähnliches setzt.

Das Ganze ohne web.xml funktioniert auch erst seit Servlet 3.0. D.h. besagter Container muss die Servlet 3.0 Spezifikation umsetzen.

Hier ist ein kleines Beispiel, das Spring Boot und Maven nutzt: http://www.leveluplunch.com/java/tutorials/037-integrate-jsf-spring-boot/
Für JavaEE7 steht eigentlich hier alles nötige: http://stackoverflow.com/questions/...page-in-java-ee-7-environment-without-web-xml

Es ist auch nicht schlimm eine web.xml zu haben, wenn es für einen selbst einfacher / schöner ist.
 
Ah ok verstehe. In der web.xml kann ja auch URL "bearbeiten" oder mit einem Filter versehen. Möchte schon aus sicherheitsgründen bestimmte Abfragen dort schon abfragen. Wäre das auch ohne web.xml möglich?

Aktuell verwende ich Jboss mit JSF und PrimceFaces als Basis. Das ist so worin ich mich einarbeiten möchte
 
JBoss? Also vermutlich Wildfly 8 mit JavaEE 7 oder?

Den oben von dir angesprochenen Bereich der web.xml benutzt man nicht für Security. Da geht's eigentlich ausschließlich darum bestimmte URL-Patterns an bestimmte Servlets durchzureichen.

Für Security gibt's in der web.xml noch einen optionalen Bereich namens <security-constraint>. Hier ist n kleines Beispiel: https://docs.oracle.com/javaee/5/tutorial/doc/bncbx.html#bnccx
Dann können nur User mit der Rolle "basicUser" auf /hello zugreifen. Viel mehr geht über die web.xml auch nicht.

In Security Frameworks, wie z.B. Spring Security, wird stattdessen ein Filter eingebunden, der bestimmte (oder alle) Requests abfängt und dann anhand beliebigen Constraints den Zugriff erlaubt oder verbietet.
Wenn du Servlet 3.0 (Wildfly 8 kann das) benutzt, kannst du sowas auch sehr simpel selbst basteln, über eine Klasse die "Filter" implementiert. Hier ein paar Beispiele: http://www.concretepage.com/java-ee...filter-in-servlet-3-with-webfilter-annotation
Innerhalb der "doFilter" Methode kannst du entweder mit "chain.doFilter(...)" den Request zum nächsten Filter weiterleiten (dabei lässt sich der Request auch vor der Weitergabe modifizieren) oder z.B. mit einem 401 Response Code antworten und die Filter-Chain direkt abbrechen.

Wenn du gerade erst einsteigst, solltest du den kompletten Security Aspekt außen vor lassen. Das lässt sich nachträglich problemlos einfügen.
 
Zuletzt bearbeitet:
hi,

richtig ich verwende wildfly8.

jetzt fällt mir gerade ein. es gibt ja auch noch die face-config. hier wird ja auch angegeben von welcher url man welche aufrufen kann. das wäre doch eher der bessere bereich um die security festzulegen.
ich möchte in meinem projekt später sowieso benutzerrollen einführen da denke ich ist dein vorschlag es nachträglich zu implementieren sinnvoll. wollte aber gern die ersten steps abklären bevor ich da jetzt richtig loslege und am ende heißt es....nope u are wrong :D
 
Zurück
Oben