Struktur einer deployten Webanwendung

---

Webanwendungen können entpackt deployed werden. Dabei wird die Struktur der Anwendung auf eine Dateistruktur abgebildet:

/applications -> das Anwendungsverzeichnis des Webservers
 + /MyApp - Application-root Verzeichnis
   + statische Inhalte, JSPs, auch in Subdirs, direkt über eine URL addressierbar
   + /WEB-INF - alles ab hier ist nicht von Clients direkt erreichbar, es muss gemapped werden!
     + web.xml -> der DD der Applikation
     + statische Inhalte, JSPs, auch in Subdirs
     + TLDs, auch in Unterverzeichnissen
     + /classes -> Verzeichnis Klassen mit Paketstruktur
     + /tags -> Verzeichnis für Tagfiles, auch in Unterverzeichnissen, hier werden sie auch ohne TLD gefunden
     + /lib -> Verzeichnis mit Java Archiven 
       + abc.jar -> ein gültiges JAR, in dem Teile der Anwendung bereit gestellt werden
         + Klassen mit Paketstruktur
         + statische Ressourcen, erreichbar mit getResource()-Methoden des Classloader
         + /META_INF
           + MANIFEST.MF -> DD des JARs
           + TLDs, auch in Unterverzeichnissen
           + /tags -> Verzeichnis mit Tagfiles, auch in Unterverzeichnissen,
                      Achtung! in einem JAR MUSS ein TLD das Tagfile beschreiben

Eine Anwendung kann aber auch als ein Archiv deployed werden. Ein solches File ist kompatibel zum ZIP Standard, hat die Endung WAR und ist genauso strukturiert wie die entpackte Variante mit folgenden Ausnahmen: i) es gibt ein META-INF Verzeichnis das einen DD des Archivs enthalten kann und ii) unterhalb von META-INF können statische, vor direktem Zugriff durch Clients geschützte Inhalte untergebracht werden.

/applications -> das Anwendungsverzeichnis des Webservers
 + MyApp.war - Die Anwendung als Archiv, der Name der Webapp ist 
               in vielen Containern dann automatisch der Name des Archivs
   + ALLES EXAKT WIE IM NICHT GEPACKTEN ZUSTAND
   + META-INF
     + MANIFEST.MF -> DD des Archivs, zum Beispiel mit Abhängigkeiten zu anderen Archiven
     + statische Inhalte, JSPs, auch in Unterverzeichnissen, 
       hier aber von Clients NICHT direkt erreichbar

Servlet Mapping

---

Servlet Mapping vermittelt von einem logischen Namen (oder Muster) zu einer physikalischen Ressource (z.B. der Servlet-Klasse). Im Deployment Descriptor:

:
<servlet>
  <servlet-name>foobar</servlet-name>
  <servlet-class>foo.bar.FooBar</servlet-class>
</servlet>
:
<servlet-mapping>
  <servlet-name>foobar</servlet-name>
  <url-pattern>/foo/FooBar.do</url-pattern> // ein logischer Pfad addressiert durch ein Pattern
</servlet-mapping>
:

Drei Pattern-Typen sind möglich und werden in dieser Reihenfolge auf Treffer geprüft:

1. explizit: /abc/action.do
2. Verzeichnis: /abc/*
3. Erweiterung: *.do

Welcome file list

---

Existiert auf ein Request zu einem Verzeichnis kein Mapping, prüft der Container auf die Existenz eines Files aus der Welcome List im DD.

:
<welcome-file-list>
  <welcome-file>index.html</welcome-file>
  <welcome-file>default.jsp</welcome-file>
  :
</welcome-file-list>

Fehlerseiten

---

Führt eine Ausnahme zum Abbruch der Seitenabarbeitung, sucht der Container nach Errorpages im DD. Das kann nach HTTP Error Code oder nach Exception-Klasse geschehen:

:
<error-page>
  <exception-type>java.lang.ArithmeticException</exception-type>
  <location>/matherror.jsp</location>
</error-page>
:
<error-page>
  <error-code>404</error-code>
  <location>/pageNotFoundError.jsp</location>
</error-page>

Referenzierung von Ressourcen im JNDI

---

Local Bean:

<ejb-local-ref>
  <ejb-ref-name>ejb/CoolBean</ejb-ref-name> --> JNDI lookup-Name
  <ejb-ref-type>Entity</ejb-ref-type>       --> Bean-Typ
  <local-home>a.b.CoolBeanHome</local-home> --> Home Interface
  <local>a.b.CoolBean</local>               --> Remote Interface
</ejb-local-ref>

Remote Bean:

<ejb-ref>
  <ejb-ref-name>ejb/CoolBean</ejb-ref-name> --> JNDI lookup-Name
  <ejb-ref-type>Entity</ejb-ref-type>       --> Bean-Typ
  <home>a.b.CoolBeanHome</home>             --> Home Interface
  <remote>a.b.CoolBean</remote>             --> Remote Interface
</ejb-ref>

Environment Variable:

<env-entry>
  <env-entry-name>abc/FooBar</env-entry-name>  --> JNDI lookup-Name
  <env-entry-type>a.b.Myclass</env-entry-type> --> beliebige Klasse mit einem Konstruktor, der ein String akzeptiert (kein Primitiv)
  <env-entry-value>ABC</env-entry-value>       --> Wert (das kommt in den Konstruktor der Klasse)
</env-entry>

Ressourcen, die über Connection Factories erreicht werden:

<resource-ref>
  <res-ref-name>jdbc/PetShopDB</res-ref-name>
  <res-type>javax.sql.DataSource</res-type>
  <res-auth>Container</res-auth>
</resource-ref>

weitere Resourcen (das sind momentan nur JMS Queues/Topics)

<resource-env-ref>
  <resource-env-ref-name>jms/stockQueue</resource-env-ref-name>
  <resource-env-ref-type>javax.jms.Queue</resource-env-ref-type>
</resource-env-ref>

Die Intitialisierung der Ressourcen und die Hinterlegung im JNDI, sowie die Verknüpfung der JNDI-Namen mit den logischen Namen im Deploymentdeskriptor ist dann serverspezifisch. Siehe dazu auch JNDI Ressourcen.

Context Parameter

---

Mit Kontext ist in der Java EE Terminologie die Umgebung des gestarteten Servlets gemeint. Im DD kann man auch für eine solche Umgebung Initialisierungsparameter bereitstellen:

getServletContext().getInitParameter("homeURL");

im DD

:
<context-param>
  <param-name>homeURL</param-name>
  <param-value>http://...</param-value>
</context-param>
:

Weitere Elemente im Deployment Descriptor

---

• Servlet Filter
• Servlet Listener
• Session Configuration
• Authentifizierung
• Autorisierung
• Security Mapping
• JSP Config - Skripting deaktivieren
• JSP Config - EL Evaluation deaktivieren
• Error Pages
• Welcome Files
• Servlet Mapping
• Servlet Init-Parameter (Context-Parameter)