Hallo Ihr beiden,

erst einmal Danke für die Hilfe.

>>> Meinem Verständnis nach geht es um folgendes: Mit <resource-ref> 
>>> refernzierst 
>>> Du ja eine externe Ressource via JNDI. Wenn diese Ressource nun bspw. eine 
>>> SQL-Datenbank darstellt, mußt Du Dich im Zweifel erst anmelden, bevor Du 
>>> tatsächlich auf die Daten zugreifen kannst. <res-auth> legt nun fest, wer 
>>> für 
>>> die Anmeldung zuständig ist, der Code Deiner WebApp selbst ("Application") 
>>> oder der Servlet-Container ("Container"). In letzterem Falle muß natürlich 
>>> der Container die zur Anmeldung nötigen Credentials kennen, d. h. Du mußt 
>>> sie 
>>> ihm auf irgendeine (Container-spezifische) Weise mitgeteilt haben.
>>> 

Ahaaaa :-)
^- ich versuche gerade den Effekt auch akkustisch zu untermalen, was
aber per Mail leider nicht möglich ist

>>> Selbst habe ich allerdings <resource-ref> noch nie verwendet, sondern immer 
>>> das Tomcat-spezifische <Resource>. Das hat den Vorteil, daß der Tomcat 
>>> gleich 
>>> einen Connection-Pool aufbaut.
>>> Der Code, um den JNDI-Lookup zu machen und sich dann bspw. die 
>>> javax.sql.Connction zu holen, ist in beiden Varianten i. w. identisch.
Naja, die Empfehlung lautet, dass man bei beabsichtigter J2EE
Kompatibilität eben genau <resource-ref> verwendet.

Die Tomcat spezifische <Resource> (empfohlener Maßen wird die in der
context.xml festgelegt) ist eigentlich nur eine Art Vorkonfiguration des
Tomcat während des Deployments. Damit wird automatisch eine Resource im
Container angelegt, damit man nicht das Admin Interface dazu bemühen muss.

<resource-ref> signalisiert dem J2EE kompatiblen Container "Cheffe, ich
brauche unbedingt diese bestimmte Resource, die Du mir bitte zur
Verfügung stellst, weil ich sonst nicht arbeiten werde." (Ähnlichkeiten
mit der Realität sind eher zufällig - aber ich wußte ja schon immer,
dass Computer auch nur Menschen sind).

Der Container hat dann die Möglichkeit entsprechend zu reagieren...

>> Ich würde diese Erklärung von Markus mit einem Beispiel bestätigen:
>> <resource-ref>
>>     <description>Creator generated DataSource Reference</description>
>>     <res-ref-name>jdbc/meine_db_verbindung</res-ref-name>
>>     <res-type>javax.sql.DataSource</res-type>
>>     <res-auth>Container</res-auth>
>> </resource-ref>
>>
>> Referenz jdbc/meine_db_verbindung wird vom Container
>> -in o.g. Fall SJSAS 8.2 verwaltet. Ich habe diese Verbindung im Server
>> eingerichtet (host,db,user,pwd usw) und meine Applikation sucht sich
>> diese Verbindung über den Namen jdbc/meine_db_verbindung:
>>
Genau, eben eine container managed resource.
Das wäre sie aber auch wenn <res-auth> auf Application steht ;-)
Sorry wegen dieses kleinen Verwirrspiels.
Die Authentifizierung gegenüber der Resource erfolgt aber über den
Container, okay.


> Hm, mir fällt gerade auf, daß wir beide es geschickt vermieden haben, den für 
> die Praxis vielleicht interessantesten Aspekt zu erwähnen, nämlich welchen 
> Einfluß der Wert von <res-auth> konkret auf den zu schreibenden Code hat.
> 
Ja, genau darauf wollte ich hinaus...

> Damit man tatsächlich mit der Datenbank arbeiten kann, benötigt es ja noch 
> eine java.sql.Connection. In Deinem Beispiel (<res-auth>Container</res-auth>, 
> Host, DB, User, Paßwort im Container konfiguriert) würde also noch etwas wie
> java.sql.Connection conn = ds.getConnection();
> gebraucht.
> Im Falle von <res-auth>Application</res-auth> wäre stattdessen etwa
> java.sql.Connection conn = ds.getConnection("<username>", "<password>");
> erforderlich.
> 
Mich würde da mal interessieren, wie man das prüfen kann, ob die
Connection schon authentifiziert ist. Wahrscheinlich gibt es nur eine
Exception wenn man das erste Mal was von der Resorce will...

> Mein langes Geschreibsel und Dein Beispielcode lassen sich im Prinzip so 
> zusammenfassen:
> Der Wert von <res-auth> legt fest, wo sich Benutzername und Paßwort für die 
> Datenbank befinden - in der Konfiguration des Containers oder direkt im Code 
> der WebApp (also mehr oder weniger direkt im Aufruf von 
> javax.sql.DataSource#getConnection) selbst.
> 
Dann ergänze ich dazu mal folgendes Beispiel:
Man stelle sich einen Web basierten Reportgenerator vor, der die
aktuellen Geschäftsdaten ausgeben soll. Die Benutzer müssen sich (wie
sich das ja auch eigentlich gehört) direkt an einer bestimmten Datenbank
authentifizieren (die ist als Resource festgelegt), damit sie auch nur
das sehen können, was ihnen der DB-Admin erlaubt hat.
Dann sollte in genau diesem Fall <res-auth> den Wert Application haben...

> Sehr interessante Frage übrigens, Patrick! Wieder was gelernt.
> 
Es freut mich immer wieder wenn andere von meinem Hirngulasch
profitieren :-)
Aber auch ich habe da wieder was gelernt.

Danke nochmal.

-- 
Gruß
Patrick

-=> Verstehe die Technik und Du findest einen Weg sie zu umgehen <=-
-- 
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org

Antwort per Email an