Verbindung von Websphere aus auf CMS-Server/Api-Zugriff

[jan]

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

[lars_wingbermue]

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!!!

[lars_wingbermue]

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 = null

Wie kann man das Thema lösen?

[isenberg]

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?

[lars_wingbermue]

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.

[isenberg]

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?

[lars_wingbermue]

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.

[isenberg]

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

[MichaelaReydt]

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

[lars_wingbermue]

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.