Verbindung von Websphere aus auf CMS-Server/Api-Zugriff
Author: jan
Publication Date: 12/1/2014 11:09
Hallo zusammen,
eine Java-Entwicklerin aus unserem Haus möchte von Websprere aus auf den CMS-Server zugreifen, um dort, über die firstspirit-Api, Datensätze in einer DB2-Tabelle zu füllen. Dabei treten Verbindungs-Schwierigkeiten auf. Hier die Beschreibung, was bisher versucht wurde:
Aus eine Java-Anwendung, welche als ear auf einem Websphere Server läuft, kann aus dem RAD keine Verbindung zum FirstSpirit hergestellt werden.
Der JUnit-Test klappt.
Auf dem FirstSpirit Server wird nichts geloggt.
Ich verwende:
Java SDP75 jdk: IBM(R) 32-bit SDK for Windows(R), Java(TM) Technology Edition, Version 6
WebSphere Version: 7.5.5.5
Der Aufruf erfolgt aus einer EJB version="3.0"
Code: Connection tConnection = ConnectionManager.getConnection(
"cms.gothaer.entw", 1088, ConnectionManager.SOCKET_MODE, "User", "PW"
);
Connection.connect();
Das Zertifikat wurde im key store eingetragen (
SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates
)
Folgende custom properties (
Application servers > Stellenmarkt > Process definition > Java Virtual Machine
) wurden gesetzt:
sun.java2d.noddraw=true
Es wurde schon ausprobiert:
Referenz auf fs-access.jar bzw. fs-webrt.jar als java build path ergibt:
de.espirit.firstspirit.common.IOError: Authorisation error - java.lang.SecurityException: Not trusted
at de.espirit.firstspirit.client.io.SocketPool.authorize(SocketPool.java:272)
Referenz auf fs-access.jar bzw. fs-webrt.jar als globaler Klassenpfad an der JVM (
Application servers > Stellenmarkt > Process definition > Java Virtual Machine
) ergibt:
The com.ibm.ws.injectionengine.factory.EJBLinkObjectFactory factory encountered a problem getting the object instance for the Reference:de.gothaer.stellenmarkt.batch.StellenmarktBatch binding object.
com.ibm.wsspi.injectionengine.InjectionException: The com.ibm.ws.injectionengine.factory.EJBLinkObjectFactory factory encountered a problem getting the object instance for the Reference:de.gothaer.stellenmarkt.batch.StellenmarktBatch binding object.
Setzen der Konstanten am ConnectionManager und holen der Connection mit servletzone bringt auch nichts:
ConnectionManager.setEncryption(ConnectionManager.
ENCRYPTION_DH_ARC4
);
ConnectionManager.setCompression(ConnectionManager.
COMPRESSION_NONE
);
ConnectionManager.setUseHttps(
false
);
tConnection = ConnectionManager.getConnection(
"cms.gothaer.entw", 1088, ConnectionManager.SOCKET_MODE, "/cms_server/", "User", "****"
);
Auch das ConnectionManager.testConnection(
"cms.gothaer.entw", 1088, ConnectionManager.SOCKET_MOD)
ergab
de.espirit.firstspirit.access.AccessIOException: Connection problem:Authorisation error - java.lang.SecurityException: Not trusted
at de.espirit.firstspirit.access.ConnectionManager.testConnection(ConnectionManager.java:484)
at de.espirit.firstspirit.access.ConnectionManager.testConnection(ConnectionManager.java:438)
Am ConnectionManager gibt folgende Konstanten:
Welche müssen wie gesetzt werden?
Müssen weitere Parameter gesetzt werden? (wo z.B. -Djava.security.policy=java.policy , -Dlocale=de ? Als JVM custom porperties gesetzt lies sich der Server nicht mehr starten )
Hat jemand schon mal so ein Problem gehabt ?
VG Jan Oltmanns
Tags: api, websphere
-
Author: lars_wingbermue - 12/1/2014 11:42
Es wurden folgenden Imports für die Klassen eingetragen:
import de.espirit.firstspirit.access.Connection;
import de.espirit.firstspirit.access.ConnectionManager;
import de.espirit.firstspirit.access.UserService;
import de.espirit.firstspirit.access.project.Project;
import de.espirit.firstspirit.access.store.IDProvider;
import de.espirit.firstspirit.access.store.Store;
import de.espirit.firstspirit.access.store.contentstore.Content2;
import de.espirit.firstspirit.access.store.contentstore.ContentStoreRoot;
import de.espirit.firstspirit.access.store.templatestore.Schema;
import de.espirit.firstspirit.access.store.templatestore.TemplateStoreRoot;
import de.espirit.firstspirit.access.Language;
import de.espirit.firstspirit.access.store.LockException;
import de.espirit.firstspirit.access.store.contentstore.Dataset;
import de.espirit.firstspirit.access.store.templatestore.Query;
import de.espirit.firstspirit.forms.FormData;
import de.espirit.firstspirit.forms.InappropriateValueException;
import de.espirit.firstspirit.forms.NoSuchFormFieldException;
import de.espirit.or.EntityList;
import de.espirit.or.Session;
import de.espirit.or.query.Select;
import de.espirit.or.schema.Entity;
Der Aufruf erfolgt dann recht simpel:
Connection tConnection = null;
try {
tConnection = ConnectionManager.getConnection("cms.gothaer.entw", 1088, ConnectionManager.SOCKET_MODE, "t0q", "*******");
tConnection.connect();
}
catch (Exception e) {
LOGGER.error("updateStellen", "", e, "Error");
throw new StellenmarktTechnicalException(e, "Fehler beim Update der Stellen im CMS (FirstSpirit)");
}
finally{
if(tConnection != null) {
try {
tConnection.close();
LOGGER.info("updateStellen()", "{}", "Verbindung zum CMS-Server wurde geschlossen.");
} catch (IOException e) {
LOGGER.warn("updateStellen()", "{}", "Fehler beim Schliessen der Connection:" + e.getMessage());
}
}
}
Klappen tut es leider nicht....
Dringende Bitte um Hilfe und Tipps!!!
0 -
Author: lars_wingbermue - 12/1/2014 11:59
Wir haben auch mal die in diesem Beitrag
ConnectionManager script stop working after .connect()
gelistete Fragestellung geprüft:
System.out.println("signers = "+ ConnectionManager.class.getSigners());
SystemOut O signers = nullWie kann man das Thema lösen?
0 -
Author: isenberg - 12/1/2014 12:21
Hallo Herr Oltmanns,
die Lösung ist hierzu, das fs-access.jar in den JVM Standard-Classpath des Websphere einzutragen, also z.B. nach was/profiles/AppServ01/classes zu kopieren.
Die Ursache ist das Abtrennen der kryptographischen Signatur des JAR-files durch den Websphere-Classloader. Innerhalb Websphere liefert die Abfrage nach der kryptographischen Signatur, die von e-Spirit erzeugt wurde, bei Aufruf von class.getSigners() nur "null" zurück und FirstSpirit prüft aus Sicherheitsgründen die Signatur, was sich nicht abschalten lässt, so dass der FirstSpirit-Server bei nichtvorhandener Signatur die Verbindung ablehnt.
Der Support seitens IBM konnte an dieser Stelle auch nicht weiterhelfen, wenn man das JAR nicht in den zentralen Classpath eintragen möchte. Die Antwort liegt aber bereits ein Jahr zurück. Vielleicht können Sie über Ihren IBM-Support einmal nachfragen, ob IBM plant getSigners() zu implementieren, falls die Lösung über den zentralen Classpath nicht akzeptabel ist?
0 -
Author: lars_wingbermue - 12/1/2014 12:45
Wir haben das Jar im Server eingetragen, das führt zu Classloading Fehlern in der Anwendung.
Das jar in das Websphere Verzeichnis kopieren geht nicht, denn dann wäre das für alle Anwendungen auf dem Server drin und kann zu interferenzen sorgen.
Gibt es einen anderen Weg?
Und der Aufruf getSigners() mit einer anderen Implementierung wäre eine Änderungsanforderung bei IBM. Wenn das überhaupt im Sinne von FS gelöst würde dann auf keinen Fall in den nächsten Monaten.
0 -
Author: isenberg - 12/1/2014 13:04
Es gibt aktuell leider keinen anderen mir bekannten Weg zur Verwendung des JARs, ohne es im zentralen Classpath des Websphere Profiles abzulegen, wo es dann tatsächlich von allen WebApps innerhalb dieses Profiles gesehen werden kann. Um welches JAR geht es denn konkret? Nur fs-access.jar? Falls ja, welche Klassen außerhalb des Packages de.espirit dort führen zu Interferenzen?
0 -
Author: lars_wingbermue - 12/1/2014 13:18
Das Risiko ist sehr groß, da dort apache-Klassen und ähnlichem enthalten sind.
Da auf dem Server ca. 70 andere Anwendungen laufen, kann ich keine umfassende Bewertung und Tests durchführen.
0 -
Author: isenberg - 12/1/2014 13:48
Mit 70 anderen Anwendungen ergeben sich unter Verwendung des fs-access.jar im zentralen Classpath tatsächlich Probleme, denn das fs-access.jar enthält unter anderem folgende Packages, die zu Interferenzen mit anderen Versionen derselben Packages führen:
org.apache.commons.compress
org.apache.commons.codec
org.apache.commons.lang
com.google.common
org.slf4j
0 -
Author: MichaelaReydt - 12/18/2014 11:32
Hallo,
wird hier noch weitere Hilfe benötigt oder konnten Holgers Antworten bereits weiterhelfen? In diesem Fall wäre es toll, wenn die "richtige Antwort" entsprechend markiert würde.
Sollte inzwischen eine eigene Lösung gefunden worden sein, wäre es super, wenn diese hier dargestellt würde.
Viele Grüße
Michaela
0 -
Author: lars_wingbermue - 12/22/2014 9:02
Hallo, wir haben das Thema umgestellt, so dass es als Java-Main-Klasse neben dem Websphere läuft.
Da es nicht zwingend eine Webanwendung sein musste, konnten wir diesen Weg gehen.
Ich halte es aber für sehr sinnvoll, diesen Deadlock zwischen Application-Server und signiertem Jar aufzulösen. Herr Isenberg wollte dies intern auch noch einmal aufgreifen.
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
9 commentaires