Tag: JEE

JavaLand 2015 & Java aktuell

Last week I visited JavaLand 2015. This great software conference [1] with lot of community activities resides in my home town Brühl [2].

Beside attending lots of tracks I had the opportunity to meet a couple of people face-to-face like Ed Burns (JSF Spec Lead), Geertjan Wielenga (NetBeans product manager), Arun Gupta (Java EE evangelist) and more, especial lot of JUG members from all over Germany. Read an article about my impressions [3].

Most slides are available for download now [4].

And I had the chance, to attend the celebration of 5 years Java aktuell, the Java magazine by the iJUG [5]. Great!

[1] javaland.eu
[2] bruehl.de
[3] heise.de/developer/artikel/developer_artikel_2591380.html
[4] javaland.eu/programm/vortragsunterlagen-zum-download.html
[5] doag.org/index.php?id=1230

CDI issue using GlassFish 4

Within a web application, you often need a state to create a session lifecycle. You may create a CDI named been with session scope, to keep track of some user data. Suppose, you have a JSF application. Assigned to your pages you might use named beans with request scope. If you need some session-wide info, you can use CDI:

@inject SessionBean mySessionBean

I moved an application which ran without known problems on GlassFish 3 to GlassFish 4. Everything worked fine, as long as I tested the app for myself. But using this app concurrent with other users, sometimes the app showed me a session timeout, could not restore a conversation or, in one case, showed me data of a concurrent user. It seemed, a SessionBean object of a different user had been injected to the request bean assigned to my request. Continue reading “CDI issue using GlassFish 4”

Tutorial web development (with JSF) XIV – Security Part III

Now, after we’ve addressed basic log-in with simple file realm, I want to move on by exchanging the authentication method. Remember, this tutorial is about web development with JavaServer Faces. All I showed for container based security so far, is technology entirely independent from JSF. Same applies to simple form log-in. But, it’s possible to embed this into some JSF techniques. And, further on, using programmatic log-in, this is done by the use of JSF. Continue reading “Tutorial web development (with JSF) XIV – Security Part III”

Tutorial web development (with JSF) XII – Security Part I

Sometimes it is crucial to protect an application or data against unauthorized access. Although there is no need to secure my tiny calculator, I’m going to demonstrate the principals of container based security by using this small app. For a description of the project, please refer to Tutorial web development (with JSF) III: Basic arithmetics.

Container provided security is not specific to JSF. It’s part of the HTTP handling and might be used by a simple servlet too. But later on, I’m going to show you, how to integrate this into a JSF application by using programmatic access. But, first of all, some background. Continue reading “Tutorial web development (with JSF) XII – Security Part I”

Interview with Arun Gupta

Arun Gupta published his book “Java EE 6 Pocket Guide”. I asked him some questions about this book and his intentions. The full interview is published by JAXenter [1]. Maybe they will publish the original English version on their English site too.

[1] http://it-republik.de/jaxenter/artikel/Arun-Gupta-praesentiert-den-Java-EE-6-Pocket-Guide-5611.html

Tutorial Webentwicklung (mit JSF) – Applikation “Rezensionen”, Teil I

In meinem Blog liste ich u.a. die von mir rezensierten Bücher. Dabei wird jedes Buch in tabellarischer Form aufgeführt.

Zu jedem Buch werden diese Informationen dargestellt:

  • Titel
  • Untertitel
  • Autor(en)
  • Verlag
  • Jahr
  • Sprache
  • ISBN
  • Kurztext
  • Verweis auf die Rezension(en)

Die Pflege erfolgt manuell und muss in jeder Kategorie bzw. Anzeigesprache eigens erstellt werden. Eine Änderung der Darstellung ist mit hohem Aufwand verbunden.

Es soll nun eine mehrsprachige Anwendung zur Darstellung der rezensierten Bücher entwickelt werden. Ziel ist, die Bücher in unterschiedlichen Anzeigesprachen sowie in unterschiedlichen Kategorien darzustellen. Dabei soll ein Buch durch Zufügen einer Kategorie in derselben gelistet werden. Die Darstellung selbst soll austauschbar gestaltet werden. Sie wird an zentraler Stelle gepflegt und automatisch für alle Bücher genutzt.
Continue reading “Tutorial Webentwicklung (mit JSF) – Applikation “Rezensionen”, Teil I”

GlassFish hinter Apache HTTP Server

Haben Sie eine Applikation mittels JSF oder anderen Techniken auf einem Applikationsserver, z. B. GlassFish, erstellt und soll diese vom Internet erreichbar sein, so können Sie natürlich den AppServer direkt an Port 80 lauschen lassen. Oft aber ist es sinnvoll, einen HTTP-Server vorzuschalten, der sich dann um Lastverteilung oder bereitstellung statischer Seiten kümmern kann.

Das folgende Beispiel zeigt, wie Sie GlassFish hinter einem Apache WebServer betreiben. Dem Beispiel liegt dieses Szenario zugrunde:

  • Die Applikation läuft unter localhost:8080/myapp
  • Die Site unter http://mydomain.net erreichbar
  • Die Site wird als virtueller Server gehostet
  • Das Verzeichnis /myapp wird auf den AppServer geleitet
  • Die Module mod_proxy.so und mod_proxy_http.so sind geladen
<VirtualHost *:80>
   ServerName mydomain.net
   ServerAlias www.mydomain.net

   ServerAdmin webmaster@mydomain.net
   DocumentRoot /var/htdocs/mydomain/

   <Directory /var/htdocs/mydomain/>
       Options Indexes FollowSymLinks MultiViews
       AllowOverride None
       Order allow,deny
       allow from all
   </Directory>

  ProxyRequests Off

  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  ProxyPass /myapp http://localhost:8080/myapp/
  ProxyPassReverse /myapp http://localhost:8080/myapp/

</VirtualHost>

Die vorliegende Konfiguration zeigt kurz, wie dies für den Apache2 konfiguriert wird. Entscheidend sind hier die Einträge unter ProxyPass(Reverse), welche das Verzeicnis (“/myapp”) auf die lokale Adresse des AppServers (“http://localhost:8080/myapp/”) umleiten. Betrachten Sie dies nur als ein Beispiel. Im Produktivbetrieb ist es aus Sicherheitsgründen ratsam, den Apache-Server in der DMZ und den GlassFish auf einer anderen Maschine hinter der Firewall zu betreiben.

Eine ausführlichere Beschreibung erfolgt möglicherweise später im Rahmen meines Tutorials.

 

Tutorial Webentwicklung (mit JSF) VII: Backstage

Backstage

[Dieser Artikel ist noch in Bearbeitung und daher unvollständig]

Bei einer traditionellen Anwendung ist es in der Regel so, dass die Applikation selbst für die Darstellung verantwortlich ist. Auch wenn Sie dafür eines Severdienstes wie X bedienen sollte, so obliegt die Steuerung dennoch dem Programm.

Anders bei einer Webapplikation. Hier werden die Daten an einen Browser übergeben, der sich um die Darstellung kümmert. Dazu verpackt der Server den darzustellenden Inhalt in ein (X)HTML-Dokument. Daneben kann der Server noch ein paar Darstellungsinformationen in Form von CSS mitliefern. Alles Weitere ist dann Sache des Browsers. Und so wie es unterschiedliche Browser gibt, kann sich auch die Darstellung unterscheiden. Die stetige Weiterentwicklung der Standards sorgt hier glücklicherweise für eine allmähliche Angleichung. Hält hier der Anwender aber ein lokales CSS vor, so kann die Darstellung wieder anders ausfallen.

Nicht nur, dass eine Webapplikation die Ausgabe an den Browser delegiert; sie wird auch nicht von selbst aktiv! Erst wenn der Anwender via Browser eine Seite anfordert, so liefert die Applikation eine solche aus. Die (scheinbar) aktive Änderung von Inhalten aufgrund von severseitiger Verarbeitung geht nicht ohne weitere Hilfsmittel. Hier lautet das Stichwort AJAX (Asynchronous JavaScript and XML). Womit wir neben (X)HTML und CSS bei einer weiteren browserseitigen Technik angelangt sind: JavaScript. Der Browser fordert zwischendurch mittels JavaScript immer wieder mal mittel pertiellem Request ein paar Daten an und tauscht Teile des Browserinhalts aus. Somit entsteht zumindest zum Teil der Eindruck, der Server aktualisiere den Bildschirm. Tatsächlich geht hier aber immer wieder eine Anfrage vom Client aus (pull). Ein echtes Push, also die vom Server veranlasste aktive Änderung der Darstellung erfordert einen tieferen Griff in die Trickkiste. Hier wird die Antwort an den Client künstlich verzögert, um zu einem späteren noch Informationen übermitteln zu können. Doch dies ist etwas für einen späteren Teil.

Bei einer traditionellen Applikation kann das Programm sofort auf eine Anwendereingabe reagieren. Bei einer Webapplikation bekommt das Programm erst dann etwas von den Anwendereingaben mit, wenn eine neue Seite oder – meist in Verbindung mit AJAX – patriell eine neue Seite angefordert wird. Zu diesem Zeitpunkt können bereits Eingaben in diversen Feldern erfolgt sein. Nicht schwer vorzustellen, dass die Applikation hiermit etwas anders umgehen muss. An dieser Stelle unterstützt JSF den Anwender und löst auf dem Server für die einzelnen Eingaben entsprechende Events aus, so dass sich ein dem Entwickler nicht ganz fremdes Programmiermodell ergibt.

Und noch ein Unterschied: Eine Webapplikation läuft meist in einer Ablaufumgebung, die ihr zahlreiche Dienste zur Verfügung stellt. Eine solche Ablaufumgebung wird als Container beszeichnet, im Falle von JSF ist dies ein sogenannter Servlet-Container. Dies deutet auf die zugrunde liegende Technik der Servlets hin. Auch bei der Entwicklung mit JSF kann die direkte Nutzung von Servlets hier und da angebracht sein. Es kann also nicht schaden, wenn Sie sich auch mit dieser Technik vertraut machen. Mehr dazu in einem späteren Teil.

Der Servlet -Container versorgt die Applikation mit Schnittstellen zu anderen Diensten. Er ist Bestandteil eines Applikations- oder auch Webservers. Zahlreiche Server beinhalten im Wesentlichen einen Container und so werden die Begriffe Container und Applikationsserver häufig synonym genutzt. Tatsächlich kann ein Server jedoch mehrere Container beherrbergen. So z.B., GlassFish, der neben Dem Servlet-Container u.a. Auch einen EJB-Container beherrbergt. Im Folgenden schauen wir von außen auf den Applikationsserver.

Wenn nun ein Anwender die Web-Applikation nutzen möchte, so ruft er in seinem Browser die URL der Anwendung auf. Der Client startet eine Anfrage an den Server. Dieser erkennt anhand der URL, dass er nicht einfach eine statische Seite ausliefern muss, sondern leitet die Anfrage über den Container an die Applikation weiter. Dort wird diese verarbeitet. Die Ausgabe wird als (X)HTML-Dokument genertiert und an den Browser verschickt. Dieser zeigt die Daten an.

<Abbildung fehlt noch>

Bei dieser Sichtweise betrachten wir den ApplicationServer al BlockBox. Interessant ist aber auch, was darin passiert. Erinnern Sie sich kurz an die bisherigen Anwendungen: Hier haben Sie jeweils eine JSF-Seite definiert. Als Seitensprache wurden Facelets eingesetzt. Jede Seite bestand neben HTML auch aus bestimmten Tags, wie beispielsweise “f:InputText”. Im Browser haben jeweils die URL einer solchen Seite angegeben. Entweder direkt oder indirekt als Angabe der Applikations-URL, die aber intern auf eine konkrete Seite verwiesen hat.

Der Server bestimmt anhand der URL die darzustellende Seite, analysiert deren Inhalt und löst die Tags auf. Im einfachsten Fall werden diese durch entsprechende Daten ersetzt. Die so entstandene Seite wird an den Browser geschickt. Dies ist aber lediglich eine vereinfachte Darstellung. Der Browser könnte ja bereits vorher Daten der Aplikation angezeigt haben. Daher prüft JSF als erstes, ob bereits eine Session besteht. Falls ja wird der Komponentenbaum, die logische Abbildung der dazustellenden Inhalte, wieder hergestellt. Eingaben werden validiert und Datenfelder upgedatet. Insgesamt unterscheidet hier JSF sechs verschiedene Phasen.

JPA und Legacy-Datenbanken

Angenommen, Sie müssen Bestellung in einer SQL-Datenbank ablegen. Eine Bestellung enthält Kopfdaten (Adresse, Datum , Nummer etc.) sowie eine variable Anzahl Zeilen (Menge, Artikel, Preis, Steuer, …). Das Ganze soll in zwei Tabellen abgelegt werden.

Table Order (
        orId Integer,
        [...]
)    

Table OrderLine (
        olId Integer,
        olOrderId Integer,
        [...]
)

Um nicht mit SQL direkt arbeiten zu müssen, setzen Sie JPA ein. Zwei Entitätsklassen, die mit den passenden Annotationen versehen sind.

Continue reading “JPA und Legacy-Datenbanken”

Tutorial Webentwicklung (mit JSF) VI: Schablonen

Schablonen

Im voherigen Teil dieses Tutorials haben wir eine zweite Seite erstellt, die in ihrem Aufbau der ersten gleicht. Nun geht es darum, die gemeinsamen Teile auch gemeinsam zu nutzen. Wir werden daher eine Schablone (template) erstellen, welche die gemeinsamen Elemente enthält und in die von den einzelnen Seiten einfach der individuelle Teil hinein kopiert wird.

Zur Erinnerung, hier nochmals der Quelltext der beiden Seiten:
Continue reading “Tutorial Webentwicklung (mit JSF) VI: Schablonen”