Migration Weblogic 5 auf 7

[Matze]

Hat im den Bereich schon mal jemand Erfahrung gesammelt?
Wo liegen die kritischen Kernpunkte bei einer Migration.
Abgesehen, vom wechsel der JDK 122 auf 14.

Welche Probleme kommen auf einen zu und wie kann man die eventuell umgehen.

Welche Auswirkungenen sind bei den EJB Container zunerwarten wird EJB 1.x noch unterstützt?

Übrigens musste ich feststellen, dass bei einer Session replizierung auf verschiedene Clusternodes deutliche Perfromance Verluste auftretten.
Wo kan man hier gezielt optimieren? Gibt es da tricks?

Gruss Matze

[Martin Jung]

Hi,

Hat im den Bereich schon mal jemand Erfahrung gesammelt?

Ich nicht.

Wo liegen die kritischen Kernpunkte bei einer Migration.

Was sind die kritischen Strukturen der gehosteten Applikation(en)? Ändern sich auch schnittstellen zu anderen Systemen (Datenbanken etc.)

Abgesehen, vom wechsel der JDK 122 auf 14.

Abgesehen? Dieser Sprung ist per se vergleichbar der Qualität des Web-Server Upgrades.

Welche Probleme kommen auf einen zu und wie kann man die eventuell umgehen.

Prinzipiell alle Probleme ;-)
Umgehen kann man sie wohl kaum, aber identifizieren und daher kontrollieren: Durch umfangreiche Test-Suites, die während/nach der Migration die Funktionalität aller (wichtigen) Komponenten beweisen bzw. bei der Wiederherstellung dieser helfen.

Welche Auswirkungenen sind bei den EJB Container zunerwarten wird EJB 1.x noch unterstützt?

Keine Ahnung.

Übrigens musste ich feststellen, dass bei einer Session replizierung auf verschiedene Clusternodes deutliche Perfromance Verluste auftretten.
Wo kan man hier gezielt optimieren? Gibt es da tricks?

Bestimmt. Vielleicht findest Du weiterführende Informationen in dafür geigneteren Informationsquellen als diesem Forum.

Viele Grüße,
Martin Jung

[Matze]

Wie inige hier im Forum, wäre es wohl besser gewesen einfach nicht´s zu schreiben als irgendwelchen misst los zu werden.

Ich glaube, wenn Du irgenwelche Testsuites nach der Migration malk sehen läst ob res klappt ist es wohl etwas zu spät oder?

Das Du keine Ahnung davon hast wie ein Releasewechsel von statten geht hast Du mir somit echt bewiesen.

Mal eine Frage,

warum glauben auch Leute die echt keine Ahnung von etwas haben immer und unbedingt antworten zu müssen??

[Martin Jung]

Hi,

schlecht geschlafen? Oder ist der Releasewechsel etwa bereits ins Stocken geraten?

Wie inige hier im Forum, wäre es wohl besser gewesen einfach nicht´s zu schreiben als irgendwelchen misst los zu werden.

Ich glaube, wenn Du irgenwelche Testsuites nach der Migration malk sehen läst ob res klappt ist es wohl etwas zu spät oder?

Ich schrieb: "während/nach".

Das Du keine Ahnung davon hast wie ein Releasewechsel von statten geht hast Du mir somit echt bewiesen.

Süß..
Da Du Dies anscheinend zu beurteilen können glaubst, musst Du über diese 'Ahnung' bereits verfügen. Warum fragst Du überhaupt? In einem Nicht-Java Forum? Unglaublich...

Martin Jung

[Matze]

Es könnte ja sein, dass hier mal jemand rein kommt wie Ich der sich eventuell damit auskennt.
Release wechsel von Version 4 auf 5 und auf 6  sind für mich nicht neu aber direkt von 5 auf 7 habe ich noch nicht gemacht und an einem Produktiven System ein bischen rumtesten ob es geht ist nicht so der richtige Weg.

Und zum zweiten nervt es mich inzwischen, dass immer wieder manche Leute auf Einträge Antworten ob Sie nun  ahnung haben oder nicht nur um mal was los zu werden.

Nicht schlecht geschlafen sondrn genervt.

Letztendlich bin ich auch kein html er und komme doch immer wieder hir rein da ich oft genug html schreiben darf weil es in jsp`s Servlets eben auch gebraucht wird.

Schade wäre froh ich käe drum herum.
Und deshalb ist es nicht unbedingt daneben geschätzt, dass hier öfters mal Java Leute rein kommen.

[Martin Jung]

Hi,

Release wechsel von Version 4 auf 5 und auf 6  sind für mich nicht neu aber direkt von 5 auf 7 habe ich noch nicht gemacht und an einem Produktiven System ein bischen rumtesten ob es geht ist nicht so der richtige Weg.

Das habe ich mit keiner Silbe auch nur angedeutet!

Erstens, nimmt man Updates/Uprades/sonstige Änderungen _niemals_ am Produktivsystem selbst vor, sondern an einem entsprechenden Entwicklungssystem. Erst wenn dieses nach Änderungen alle Tests (Black-/Whitebox, Integration etc., je nach Komplexität der Applikation) erfolgreich durchlaufen hat, wird es für die Produktion freigegeben.
Zweitens, lautete mein allgemeiner Vorschlag auf eine allgemeine Frage, durch Verwendung von TestSuites einen Systemwechsel kontrolliert durchzuführen.
Dass man, um einen prominenten Aspekt aufzugreifen, sinnvollerweise zuvor die Applikation in geeignete Teilkomponenten zerlegt, um diese (weitesgehend) isoliert zu portieren, was dabei (mit Sicherheit) auftretende Fehler/Probleme schnell(er) lokalisieren und beheben hilft, habe ich nicht explizit erwähnt (nur fragend angedeutet). Dies, weil ich annahm, dass in einem Weblogic-Project solche grundlegende Vorgehensweisen vorauszusetzen sind. Nach welchen Kriterien dieses 'Runterbrechen' dann erfolgen kann/sollte, hängt von den konkreten technischen und funktionalen Eigenschaften/Anforderungen der Applikation ab. Dazu hast Du bisher keine Angaben gemacht - und ich hatte keine Lust danach zu fragen.

Und zum zweiten nervt es mich inzwischen, dass immer wieder manche Leute auf Einträge Antworten ob Sie nun  ahnung haben oder nicht nur um mal was los zu werden.

Mich nerven unbelegte Behauptungen. Welches meiner Statements erlaubt Dir den Schluss, ich hätte 'keine Ahnung'? Wenn die Antworten Dir nicht passend erscheinen, überdenke vielleicht die Art Deiner Fragestellung und/oder den Umfang der von Dir gelieferten Informationen.

Martin Jung

[Matze]

Aha,

nun gut dann lasse ich Dir Deine Ahnung.
In unserem Hause ist jedes System "Produktiv" welches in einem QS oder Produktionsprozess befindet.
Der Aufwand eine grössere Applikation die an verschiedenen Datenbankservern hängt sowie eine gewisse Infrastruktur vorraussetzt ist hier einfach nicht mehr realisierbar.

Nur mal schnell einen Testserver online zu bekommen würde hier mindestens 1 Monat dauern.
Freigabe durch die Security wäre das kleinste Problem.

Dass ich bestimmt nicht den für die Kunden drausen betriebenen Server als erstes migriere ist ja wohl keine Frage.
Jedoch ist aus Sicht der QS die Entwicklergruppen ebenfalls Kunde.
Die bezahlen dafür, dass die QS eine Testumgebung zu verfügung stellt die jetzt auf Bea 7 migriert werden soll. Par definition ist somit dieses System ebenfalls produktiv.

Mein Fragestellung war lediglich diese:
Was zu beachten ist und welche Probleme auf einen zu kommen.
Nicht ob ich dafür einen Testfall bauen muss.
Was soll den die Testsuite deines erachtens prüfen ob der Server hoch fährt und was er für Fehlermeldungen von sich gibt?
Dafür gibt es Logfiles und das Auge, das erkennt, dass der Server nicht hoch fährt. Mehr kannst du dabei nicht testen.
Danach muss so oder so getestet werden.

Die Frage was man vorher zu beachten hat kannst du nicht beantworten.
So fragen, können weiterhin war Archive deployt werden.
Müssen bestimmte konfigurationen geändert werden.

Teilweise weiss ich inzwischen, dass viele Konfigurationen angepasst werden müssen.
Ein deployment descriptor sieht völlig anderster aus.
Und wenn man das Domänen konzept von Bea seit V7 nützen möchte gibt es eine ganz hand voll zu beachten.

Die Realms von Bea haben sich stellen weise geaendert.
EJB 1.1 und 2.0 gleichzeitig zu deployen nicht ganz ohne Probleme.
Das Ziel alles auf 2.0 bringen.

Einfach mal behaupten hach dafür brauchst Du eine Testsuite ist ein prima Aussage ohne zu wissen was Du testen willst.
Und allein beim deployment und starten der Server macht eine Testsuite sehr viel sinn.....
Und danach ist es zu spät!!

Wenn der neue Server läuft. Der auch parallel zum alten betrieben werden könnte, will ich nicht erst dann oder beim starten die Probleme herausfinden sondern schon im vorfeld die gesammte Entwicklung davon informieren wo welche Änderungen notwendig werden.
Um den grössten Teil der Probleme... -> deployment.xml falsch
welche kleiner Ursache sind erschlagen.
Weil für spielchen Ach jetzt geht das nicht mehr und dieses...
haben wir und auch ich keine Zeit.

Deswegen ist eine evaluierung schon von vorne herein notwendig.

Und deswegen behaupte ich nochmals, Du bist bestimmt ein toller Entwickler aber von migrationen und deren notwendigkeiten hast du keine Ahnung. Und QS setzt eine gute Planung voraus.

Eine Testsuite ist an der Stelle zu spät.
Denn wenn dann muss die Testsuit nur noch schauen ob das was migriert wurde wieder läuft.

Dazu muss jedoch der APPserver auch hoch fahren.
Und damit der sicher hoch fährt ist es vorher schon wichtig möglichst alles auf dem Stand zu haben, dass es läuft.
Fehler tretten dann mehr als genug auf.

Weisst du wieviel Geld es kostet, wenn ein System steht und die Entwickler (in diesem Projekt 150) darauf warten weiter zu machen?
Da kann ich lange recherchieren dafür.