Java: Zugriff auf DTQ aus ServletContainer bei Redeployment

[Haunted]

Hallo zusammen,

ich habe ein Problem mit dem Zugriff auf die AS400 aus einem ServletContainer (Jetty) heraus.

Beim erstmaligen deployment funktioniert alles wunderbar (die DTQ kann angelegt werden). Sobald ich mein WebProjekt allerdings redeployen will, bekommen ich bei dem oben genannten erzeugen der DTQ eine Exception:


java.lang.UnsatisfiedLinkError
at java.lang.Throwable.<init>(Throwable.java:181)
at java.lang.Error.<init>(Error.java:37)
at java.lang.LinkageError.<init>(LinkageError.java:26 )
at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedL inkError.java:25)
at com.ibm.as400.access.AS400ImplRemote.swapTo(AS400I mplRemote.java:2393)
at com.ibm.as400.access.AS400ImplRemote.signon(AS400I mplRemote.java:2172)
at com.ibm.as400.access.AS400.sendSignonRequest(AS400 .java:2900)
at com.ibm.as400.access.AS400.promptSignon(AS400.java :2503)
at com.ibm.as400.access.AS400.signon(AS400.java:3791)
at com.ibm.as400.access.BaseDataQueue.chooseImpl(Base DataQueue.java:223)
at com.ibm.as400.access.DataQueue.create(DataQueue.ja va:131)
at com.ibm.as400.access.DataQueue.create(DataQueue.ja va:78)
......


Wenn ich den Server allerdings komplett restarte funktioniert es wieder wie gehabt. Desweiteren wird das Javaprogramm direkt auf der AS400 ausgeführt.

Hat jemand eine Idee an was dies liegen könnte ?

Danke.

[Fuerchau]

Wenn ich mir den Stack so ansehe, möchte sich dein Programm mittels Logon-Maske anmelden.
Das geht aber auf der AS/400 nicht und schon gar nicht im Batch.

Für den Vorgang musst du bereits einen Benutzer mit Kennwort für dein AS400System-Objekt mitgeben, so dass keine Dialog-Anmeldung erforderlich ist.

[Haunted]

Hi,

danke für deine Antwort, ich werde es einmal ausprobieren ob es dann damit funktioniert.

Aber was ich mich frage, wenn es an dem Logon ansicht liegt, warum kommt dieser Fehler nur beim Redeployment, nicht aber beim ersten Deployment?

Bzw. nach einem kompletten Restart des ServletContainer funktioniert es auch wieder.

[Fuerchau]

Das kann ich dir auch nicht sagen, ggf. schlägt irgendwo eine Cachefunktion zu.
Besser ist es auf jeden Fall, eine Anmeldung per Programm selber zu machen, im Batch ist selten ein User verfügbar .

[Haunted]

Hallo,

ich habe es nun einmal ausprobiert, das AS400 Object mit Username und Passwort zu instanzieren, leider kommt immernoch eine ähnlich (wenn nicht gleich) aussehende Exception:

java.lang.UnsatisfiedLinkError
at java.lang.Throwable.<init>(Throwable.java:181)
at java.lang.Error.<init>(Error.java:37)
at java.lang.LinkageError.<init>(LinkageError.java:26 )
at java.lang.UnsatisfiedLinkError.<init>(UnsatisfiedL inkError.java:25)
at com.ibm.as400.access.AS400ImplRemote.swapTo(AS400I mplRemote.java:2393)
at com.ibm.as400.access.AS400ImplRemote.signon(AS400I mplRemote.java:2172)
at com.ibm.as400.access.AS400.sendSignonRequest(AS400 .java:2916)
at com.ibm.as400.access.AS400.promptSignon(AS400.java :2503)
at com.ibm.as400.access.AS400.signon(AS400.java:3791)
at com.ibm.as400.access.BaseDataQueue.chooseImpl(Base DataQueue.java:223)
at com.ibm.as400.access.DataQueue.create(DataQueue.ja va:131)
at com.ibm.as400.access.DataQueue.create(DataQueue.ja va:78)

gibt es noch andere Möglichkeiten ?

[BenderD]

solange du nur die Fehlermeldung ohne den Code vorzeigst, ist das alles fruchtloses Ratespiel

D*B

[Haunted]

Hallo,

damit hast du natürlich recht, ich habe die betroffenen QT einmal herausgesucht:


AS400 as400 = new AS400("MaschinenName"); //Hier wurde auch schon zusätzliche UserID + PW ausprobiert

this

.dataqueue = new DataQueue(as400, "nameDerQueue");

try {

this.dataqueue.create(64512);

this.dataqueue.clear();
} catch (Exception e) {

}

Die Exception wird bei der create Methode geworfen.

Mehr QT gibt es dazu auch nicht, auser das das ganze wie gesagt innerhalb eines ServletContainers läuft.

[BenderD]

... bist du denn sicher, dass du an dieser Stelle rausdüst? ich würde da erst mal ein logging statement einbauen (und am Besten gleich log4j einbauen).
- 2. Kandidat ist eiin Bug in dem Dollschachtel Kram (andere Version probieren)
- 3. Kandidat ist ebenfalls caching, probier mal ein
as400.resetAllServices()
- 4. vielleicht geht ja auch ein as400.finalize() - sollte mich allerdings wundern
- 5. mit Jetty habe ich keine Erfahrung, ob man da die Applikation raushauen kann, ohne den kompletten Container runterzufahren
- 6. Wenn Du hier landest, dann geht Hot Deployment wohl nicht.

D*B

[Haunted]

Hi,

ja es ist diese Stelle.

Ein resetAllServices bzw finalize habe ich auch schon ausprobiert, allerdings ohne Erfolg.

Probiert habe ich dies auf einer 1.5 VM und 1.6 VM (hoffe du meinst das mit andere Version?)

Und zu dem Jetty also es geht "normal" ich kann halt nur nach einem redeployment anscheinend nicht mehr mit dem AS400 Object arbeiten, aus welchem Grund auch immer.

[Fuerchau]

Wie gesagt, es wird ein Signon versucht den du unterbinden musst:
AS400 class

Hier findest du alles bezüglich Anmeldung, Unterdrückung und Caching.

[BenderD]

... die Java Version ist da Banane, die Dollschachtel Version könnte man noch probieren (jt400).
@Baldur: das ist genau umgekehrt!!! Der (erneute) Signon müsste erzwungen werden (dieser Spielzeugkasten von Toolbox hat sich da was unvollständig gecached)

D*B

Hi,

ja es ist diese Stelle.

Ein resetAllServices bzw finalize habe ich auch schon ausprobiert, allerdings ohne Erfolg.

Probiert habe ich dies auf einer 1.5 VM und 1.6 VM (hoffe du meinst das mit andere Version?)

Und zu dem Jetty also es geht "normal" ich kann halt nur nach einem redeployment anscheinend nicht mehr mit dem AS400 Object arbeiten, aus welchem Grund auch immer.

[Fuerchau]

Wenn ich dem AS400-Objekt Benutzer und Kennwort übergebe und den Anmeldedialog unterdrücke, der laut Doku sonst wohl immer kommt, sollte es eigentlich klappen.

Bei ODBC muss ich dem Treiber ja auch sagen, dass er gefälligst den Prompt unterdrücken soll, ist ja keiner da, der das dann machen kann.