Zugriff auf Oracle DB aus einer Application des J2ee App.Servers

[Ralf Hying]

Hi<p>
ich habe eine kleine Application (Servlet, BMP Entity Bean) erstellt, welche ich mit dem deploytool des j2sdk1.3 auf den j2ee ApplicationServer starten konnte. Die Bean soll nun auf eine entfernte Oracle Datenbank zugreifen. Der Treiber ist korrekt eingrbunden (J2EE_CLASSPATH, j2eeadmin -addDriver). Die DataSource ist im deploytool auch eingestellt(jdbc/Oracle), und mit j2eeadmin -addDataSource hinzugefügt. <br>
Wenn nun die Bean versucht eine Connection aufzubauen:<p>
<i>DataSource ds = initContext.lookup( "java:env/conv/jdbc/Oracle" )<br>
Connection con = ds.getConnection())
</i><br>
bekomme ich die Meldung : <br>
<i> java.security.AcessControlException: access denied(java.lang.RuntimePermission loadLibrary ocijdbc8)</i><p>

An der Stelle hilft es auch nicht über den DriverManager.getConnection(url, user,passwd) zu gehen, das gibt den gleichen Fehler.<br>
Allerdings funktioniert es, wenn ich mit dem DriverManager aus VisualAge heraus ein Verbindung aufbaue. <p>

Wenn mir bein diesem Problem jemand weiterhelfen kann, wäre das total super!!! Danke schon mal.<br> Ralf

[tp]

Hi,

jedes Java-Programm ab 1.2 (also auch die J2EE 1.3 Ref.Impl.) verfügt über die Möglichkeit, mit sogenannte Policy-Dateien den Zugriff als Nutzer einzuschränken. Das sieht dann so aus:

<code>java -Djava.security.policy=yourpath/yourfile TheClass</code>

Wenn Du mal in die Hilfe zu RuntimePermission reinschaust, wird auch einiges klarer.

Lösung:<br>
a) Die .policy-Datei der J2EE suchen, mit policytool (jdk-root/bin) die Permission einfügen.<br>
b) Neue Policy-Datei anlegen:<br>
<code>
grant {<br>
permission java.security.AllPermission;<br>
};<br></code>

c

[tp]

Endlich wieder mal ein Kommentar im EJB-Teil :

[Ralf Hying]

<b>Danke nochmals Thomas,</b><br>
das hat funktioniert. Ich weiß zwar nicht genau welche Auswirkungen diese Änderungen hatten, aber es läuft. Zu welchem user werden denn nun alle Rechte vergeben? Oder bezieht sich das nur auf den Server??? <p><br>
<b>Neues Problem:</b><br>
Ich möchte über meine entity EJB verschieden Suchfunktionen anbieten. Dazu sollen die Suchkriterien immer weiter verfeinert werden. Das heißt, ich möchte auf den Ergebnissen meiner ersten Suche weiter aufbauen. Muß ich dazu über die EJB-Objekte gehen, oder kann das auch innerhalb der Datenbank auf effizientere Weise(SQL) laufen.?<br> Ich stelle mir vor ich habe bei der erste Such 1000 Treffer, und möchte nun auf diesen Treffen mit einem weiteren Suchkriterium filtern. Wenn im EJB-Server nun zu jedem Treffer aus der Findermethode ein Object erzeugt wird, mit dem ich weiterarbeiten kann, dann dauert das doch eine Ewigkeit, oder?(ich hab´s noch nicht ausprobiert)<br>
Innerhalb der Bedingungen wird auch auf andere Tabellen (join) verwiesen und Attribute abgefrage. Spätestens bei der Verfeinerung wird es schwierig. Wie kann ich sowas lösen?<br>
Könnte eine Lösung sein, daß ich einfach eine Methode anbiede die den SQL selecte string als Parameter übergibt, und ich nur die Anzahl der Treffer zurückgebe(count). Eine Suchverfeinerung kann dann aber nur in der Art sein, daß ich weitere Bedingungen anhänge, und nicht auf dem ResultSet weiter suche.<br><p>
Noch was: Bei jeder set- und get- Methode wird eine Datenbankverbindung angefordert und mehrere Transaktionen getätigt. Besteht eine Gefahr darin, wenn die Verbindung in EJBActivate aufgebaut wird, und die Trasnaktion erst in EJBPassivate abgebaut wird(conn.commit() bzw conn.close())? In der Regel dauert ein set/get Methode nicht so lange. <p>
Wieder mal bedanke ich mich für die Unterstützung! <p>Grüße Ralf

[tp]

Hi Ralf,

Deine Änderung bewirkt nicht die Änderungen irgendwelche User-Rechte, sondern die Änderung von Rechten der VM. In java.policy steht drin, was Java (konkret: diese Java-Instanz) auf dem Rechner darf und was nicht.<p>
Für Deine Suchkriterien brauchst Du ne hochentwickelte OR-Mapping-Schicht. Der kannst Du in der Finder-Methode sowas wie ne SQL-Klausel übergeben, aber natürlich nicht objektorientiert. In der Regel ist so ziemlich jede OR-Technologie für EJB heutzutage dazu in der Lage . Die schlechten Nachrichten sind nur:<br>
1) Das gibt es garantiert nicht für die J2EE Referenzimpl. von Sun<br>
2) Sowas ist alles überhaupt nicht standardisiert und schränkt die Portabilität auf die Verfügbarkeit der OR-Tech ein.<br>
3) Auch EJB 2.0 wird nicht besser .<br>
<p>
Wenn Du dann schon direkt mit SQL auf die Datenbanken willst, dann tu das in den Session-Beans. An Finder-Methoden nen count zurückzugeben ist schon wegen des Lifecycle kritisch. Trotzdem gefällt mir diese Lösung nicht, weil Du Dann eigentlich keine EJBs brauchst. Mit OR-Technologien entwickelt man aber sowieso nur CMP, deswegen würde dieser Punkt wegfallen.<p>
Datenbankverbindungen sollten vom Server per JNDI zur Verfügung gestellt werden, dann werden Sie vom Server geöffnet und verwaltet, so wie du es schon tust. Wenn Du die DB dann brauchst, forderst Du Sie an (setSessionCTX). In den set/get-Methoden direkt auf die DB zu gehen ist außerdem kritisch, denn das Ändern von 3 Attributen über se-Methoden bedeutet dann 3 DB-Operationen. <p> Zusätzlich kommt dazu, daß dann für jede Methode eine TX auf AppServer- und damit auch DB-Seite aufgemacht wird. Hier helfen nur Session Beans, die Anwendungsfälle kapseln (session wraps entity-pattern, Trennung Daten-Werkzeug, Kapselung der eigentlichen Geschäftsoperationen - Namen gibt es viele).<p>
c