MCRServlet
Das Zusammenspiel der Servlets mit dem MCRServlet
Als übergeordnetes Servlet mit einigen grundlegenden Funktionalitäten dient die Klasse MCRServlet
. Die
Hauptaufgabe von MCRServlet
ist dabei die Herstellung der Verbindung zur Sessionverwaltung
(siehe Abschnitt Die Session-Verwaltung). Das Zusammenspiel der relevanten Klassen ist im Klassendiagramm
(Abbildung 2.5) verdeutlicht.

Abbildung 2.5: Klassendiagramm Common Servlets
Wie an anderen Stellen im MyCoRe-System auch, kann auf Konfigurationsparameter wie zum Beispiel den Einstellungen
für das Logging über das statische Attribut MCRConfiguration
zugegriffen werden.
MCRServlet
selbst ist direkt von HttpServlet
abgeleitet. Sollen andere Servlets im
MyCoRe-Softwaresystem die von MCRServlet angebotenen Funktionen automatisch nutzen, so müssen sie von
MCRServlet
abgeleitet werden. Im Klassendiagramm ist das durch die stellvertretende Klasse
MCRAnyOtherServlet
angedeutet. Es wird empfohlen, dass die abgeleiteten Servlets die Methoden
doGet()
und doPost()
nicht überschreiben, denn dadurch werden bei einem eingehenden
Request auf jeden Fall die Methoden von MCRServlet
ausgeführt.
Der Programmablauf innerhalb von MCRServlet
ist im folgenden Sequenzdiagramm (siehe Abbildung 2.6)
dargestellt. Bei einem eingehenden Request (doGet()
oder doPost()
) wird zunächst
an MVRServlet.doGetPost()
delegiert. (Bei dieser Delegation wird ein Parameter mitgeführt, über den
feststellbar ist, ob es sich um einen GET- oder POST-Request gehandelt hat.)

Abbildung 2.6: Sequenzdiagramm Common Servlets
Falls nicht schon aus vorhergehenden Anfragen an das MCRServlet
bekannt, werden in
doGetPost()
die Base-URL und die Servlet-URL des Systems bestimmt. Dabei besteht die Servlet-URL
aus der Base-URL und dem angehängten String 'servlets/
'. Darauf folgend wird die für diese Session
zugehörige Instanz von MCRSession
bestimmt. Das Verfahren dazu ist im Ablaufdiagramm (Abbildung 2.7)
dargestellt.
Die Session kann bereits durch vorhergehende Anfragen existieren. Falls dies der Fall ist, kann das zugehörige
Session-Objekt entweder über eine im HttpServletRequest
mitgeführte SessionID identifiziert oder
direkt der HttpSession entnommen werden. Existiert noch keine Session, so wird ein neues Session-Objekt über den
Aufruf von MCRSessionMgr.getCurrentSession()
erzeugt. Nachfolgend wird das Session-Objekt an den
aktuellen Thread gebunden und zusätzlich in der HttpSession abgelegt.
Im Sequenzdiagramm gehen wir davon aus, dass die Sitzung neu ist und deswegen ein Session-Objekt über
MCRSessionMgr.getCurrentSession()
erzeugt werden muss. Schließlich wird eine Instanz von
MCRServletJob
erzeugt. Diese Klasse ist nichts weiter als ein Container für die aktuellen
HttpServletRequest und HttpServletResponse Objekte und hat keine weitere Funktionalität (siehe Klassendiagramm,
Abbildung 2.5). (Das Speichern des Session-Objekts in der HttpSession ist notwendig, weil in einer typischen
Servlet-Engine mit Thread-Pool Umgebung nicht davon ausgegangen werden darf, dass bei aufeinander folgenden Anfragen
aus demselben Kontext auch derselbe Thread zugewiesen wird.)

Abbildung 2.7: Ablaufdiagramm für MCRServlet.doGetPost()
An dieser Stelle wird der Programmfluss an das abgeleitete Servlet (in diesem Beispiel
MCRAnyOtherServlet
) delegiert. Dazu muss das Servlet eine Methode mit der Signatur
public void doGetPost(MCRServletJob job) {}
implementieren. Wie das Sequenzdiagramm beispielhaft zeigt, kann MCRAnyOtherServlet
danach
gegebenenfalls auf das Session-Objekt und damit auf die Kontextinformationen zugreifen. Der Aufruf an den
SessionManager dazu wäre:
MCRSession mcrSession=MCRSessionMgr.getCurrentSession();
Es sei bemerkt, dass dies nicht notwendigerweise genau so durchgeführt werden muss, da wegen der geschilderten
Probleme mit threadlocal
Variablen in Servlet-Umgebungen das Session-Objekt auch in der HttpSession
abgelegt sein muss, könnte man die Kontextinformationen auch aus der übergebenen Instanz von
MCRServletJob
gewinnen.
Thomas Scheffler - 2017-06-27