Autor Thema: gerade bewarheiten sich meine düstersten Visionen, warum ich immer für Webservic  (Gelesen 3375 mal)

Offline flaite

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 2.966
    • mein del.icio.us
es war.

JCo ist eine recht häufig verwendete Bibliothek zur Integration von SAP.
Nun hat ein Kunde nach einem upgrade auf Domino 8.5 offenbar Probleme mit einer Anwendung, die stark JCo verwendet.
Und dann les ich bei der Recherche:
Zitat
Noch ein Tipp! JCo läuft nicht unter Java5, weil in Java5 die toString()-Methode von BigDecimal verändert wurde und die alte Mimik nun in "toPlainString()" liegt. JCo berücksichtigt das in der Version 2.1.8 noch nicht - benötigt aber intern den BigDecimal zur Darstellung von Zahlen. (oder ist endlich eine Java 5 fähige Version draußen und ich habe es nicht bemerkt?)
Der Umstieg auf JCo 3.0 - die läuft mit Java5 und Java6 - erfordert offenbar noch ein paar weitere Änderungen am Code.
http://help.sap.com/saphelp_nwpi71/helpdata/de/46/fb7ff9c7b46c30e10000000a1553f7/content.htm

Man kann die Java VM für Domino8.5 nicht einfach auf Java1.4 downgraden, oder?

Sun bzw. Oracle macht sich immer Mühe mit der Abwärtskompatibilität neuer Versionen. Praktisch alle openSource Projekte ebenfalls. Nur bei so kommerziellen Libs kanns möglicherweise anders aussehen, wenn die vorher recht obskure features genutzt haben. Mit REST Webservices für die Integration wäre das alles nicht passiert.

Kennt jemand vielleicht ein maintenance release von JCo, das mit Java5 und Java6 läuft?


Gruss Axel
Ich stimm nicht mit allen überein, aber mit vielen und sowieso unterhaltsam -> https://www.youtube.com/channel/UCr9qCdqXLm2SU0BIs6d_68Q

---

Aquí no se respeta ni la ley de la selva.
(Hier respektiert man nicht einmal das Gesetz des Dschungels)

Nicanor Parra, San Fabian, Región del Bio Bio, República de Chile

Offline Christian Huber

  • Frischling
  • *
  • Beiträge: 11
Hallo,

ich hatte (oder hab) dasselbe Problem ergänzt um 64bit.

Domino 8.5.1 FP3 64bit, Windows Server 2008 64bit

"Could not load middleware layer", etc. etc.

Hab mit gestern bei MegaUpLoad alle Versionen der 2.1.8 geholt (bei Sap gibt's die nicht mehr), da die Umstellung auf 3.0 nicht nur aufwändig ist,
sondern auch durch die mangelnde Abwärtskompatibilität immer 2 Versionen erforderlich sind.

Eine Idee ist folgendes.

Die JRE 1.4 direkt in die Projektproperties der Javalib/des Agenten einbinden, dann sollte das Problem auch bei höheren
Version nicht auftauchen (macht das Ganze natürlich um 25MB größer).

Andererseits kann ich folgendes nicht nachvollziehen

JCO 2.1.8 läuft nicht unter Java 5/6.

Ich habe die JCO ganz normal an einem 8.5.1 Client am Laufen mit Java Rte 1.6.
Vielleicht verwende ich zufälligerweise nicht die Sachen, die angeblich nicht mehr laufen, aber an und für sich
soll ja toString() nicht gehen und das wird hier intensiv genutzt.

Oder (da Entwicklungsumgebung=6.5.6), die Javalibraries compilieren in der Quellumgebung alles rein und verwenden
im Zielsystem dann nur intern (was ja eigentlich Quatsch ist, dann wäre ja das Rte im Zielsystem gar nicht erforderlich).

Ich muss mal probieren, was passiert, wenn man unter 8.5.1 mit jre 1.6 kompiliert.

Die Java VM kann man schon downgraden, aber das ist nicht empfehlenswert, da dann 1000 andere Sachen notesintern
nicht mehr laufen. Besser ist wie gesagt der obige Weg mit der direkten Einbindung, da dann andere
Applikationen nicht gestört werden.

Ich hab z.B. in einer Anwendung 2 Applets, die mit 1.4 und 1.5 kompiliert wurden und dann die Klassen direkt in die
Libraries (Projectproperties) eingebunden wurden. Das läuft perfekt unter allen Version 5-8.

Wenn Du von anderer Stelle schon irgendwelche Info'S hierzu hast, wäre nett, da was mitzubekommen.

bye
Christian

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz