Java: Zugriff auf DTQ aus ServletContainer bei Redeployment

[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.

[Haunted]

mh, also ich habe das AS400 Object schon einmal testweise so erzeugt:

AS400 as400 = new AS400("maschine","userID","PW")

aber auch damit kam der gleiche Fehler.

Oder meintest du etwas anderes ?

[BenderD]

... das erklärt nicht, dass es beim Neustart des ServletContainers läuft und nach HotDeployment nicht. Der Neustart des Servers schmeißt die JVM komplett raus und lädt selbige dann neu - und alles funzt.
Ein Hot Deployment der bereits laufenden Anwendung hat noch irgendwelche Reste des (untauglichen) Versuchs das AS400 Object zu cachen und es knallt!

D*B

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.

[Haunted]

Ich muss auch noch dazusagen das ich auch schon versucht habe, die Klasse AS400 mit unterschiedlichen Classloadern zu laden (einmal der Parentclassloader von jetty) und einem den Contextclassloader(Subclassloader), da ich vermutete das hier vlt etwa schiefgeht, allerdings konnte ich auch damit das Problem nicht beseititgen.

[Fuerchau]

Dann probier doch folgendes:
AS400

voidsetGuiAvailable(boolean guiAvailable)
Sets the environment in which you are running.

[Haunted]

Hallo,

auch die GUIAvailable funktion hatte keinen Efekt auf die Exception.

Ich habe zusätzlich nocheinmal ausprobiert einen ConnectionPool zu verwenden, mit dem gleichen Resultat wie ohne.

[RobertPic]

Folgende Versuche:
- aktuellsten Treiber von JTOPEN versuchen (hat Dieter schon geschrieben)

Plan "B":
- die JT400/JTOPEN aus dem Projekt nehmen und in die Jettyumgebung kopieren - damit sollten die Treiber vom Hotdeployment nicht betroffen sein.

Optimal wäre natürlich ein Connectionpool auf Serverebene (nicht auf Projektebene), aber die meisten Beispiele beschreiben hier nur JDBC-Pools, für die AS400-Communication müsste man wahrscheinlich was "basteln".

Mich irritiert dein Satz "das Javaprogramm läuft auf der AS/400" vom 1. Post - welches Javaprogramm? oder rennt der Server auf der AS/400?

[Haunted]

Hallo,

mit dem Satz meinte ich das der Jetty in dem die Anwendung deployt wird, direkt auf der AS400 läuft.

Die jt400.jar wird ja direkt aus der JRE Umgebung geladen wenn ich mich recht erinnere, ich werde dies aber einmal genauer prüfen.

Danke für eure Hilfe.

[Haunted]

Hallo zusammen,

es lag wirklich an der jt400.jar, nachdem ich diese aus dem lib Verzeichnis entfernt hatte, trat der Fehler nicht mehr auf.

Danke für eure Hilfe

[RobertPic]

Mehrfach Angaben von Jar's, von unterschiedlichen Classloadern und wahrscheinlich auch noch unterschiedliche Versionen (jt400.jar auf der AS/400 und im Webprojekt) haben eben ein gewisses Fehlerpotenzial.

Mit dem jt400.jar/jtopen.jar (allerdings nur 1x) hatte ich bislang noch keine Probleme.

mit dem Satz meinte ich das der Jetty in dem die Anwendung deployt wird, direkt auf der AS400 läuft.

Hätte ich auch so verstanden, war nur etwas ungläubig, dass jemand einen Javaserver nicht auf x86-Hardware fährt.

Aber immer noch besser wie das Monster Websphere Appl. Server. Ich glaue IBM zählt die (nicht benutzten) "Zwangsinstalltionen" bei allen IBM-Servern mit - anders kann ich mir die Verbreitung (Nr.1 JEE-Server) auch nicht erklären.....