it-swarm.com.de

Vorteile (und Tipps) eines Upgrades von JBoss 4.2.x auf JBoss 5.x, 6.x, 7.x und WildFly 8.x?

Bitte nehmen Sie an, dass ich mich nicht um Entwicklungszeit und -kosten kümmern muss: Ich bin an allgemeinen technischen Vorteilen (verbesserte Leistung? Verbesserte APIs?) Und neuen Funktionen interessiert.

Ich arbeite derzeit an Produkten, die 4.2.x verwenden, und wir denken über eine bedeutende Verschiebung für Versionen nach, die lange auf sich warten lassen und konvergieren müssen.

Ich habe mir die Versionshinweise jeder Version und einige Artikel zu jeder Version für 5.x, 6.x, 7.x und 8.x angesehen. Ich würde mich aber über Feedback aus erster Hand von Leuten freuen, die den Wechsel vorgenommen haben.

Ich habe festgestellt, dass es einige wichtige Änderungen im Zusammenhang mit Messaging gibt (Umstellung von JBoss MQ auf JBoss Messenging), und dass es für JBoss 7.x die Konfigurationsebene ein wenig zu ändern scheint. Dann ist beim Wechsel zu JBoss/WildFly 8.x noch viel mehr los.

Bitte empfehlen Sie gute Artikel, die auf Fallstricke hinweisen, wenn Sie können. Ich habe einige für Migrationen zu JBoss 5.x gefunden, aber nicht so viele für 6.x oder sogar 7.x, und jemand anderes evaluiert 8.x für uns. Sie können auch Alternativen empfehlen, wenn Sie diese für relevant halten. Ich würde mich jedoch lieber nur auf JBoss konzentrieren.

Zur Information verwenden wir eine Mischung aus JPF- und OSGi-fähigen (unter Verwendung von Eclipse Equinox) Plugin-basierten Systemen, wobei die Clients in Swing entwickelt wurden (einige werden über WebStart bereitgestellt).

Update: Obwohl diese Frage bereits einige gute Antworten gebracht hat, denke ich, dass es ein Update für WildFly verdient (und tatsächlich haben unsere internen Projekte die Umstellung von 4.2.x auf 7.x verzögert, wie ursprünglich geplant, um auf WildFly zu warten) . Neue Gedanken und Antworten sind willkommen.

31
haylem

Ich habe ein Upgrade von JBoss 4 auf 5 durchgeführt und aus Erfahrung sind die folgenden am wichtigsten zu beachten:

  • JBoss 5 (und 6 und 7) sind nicht so fehlerverzeihend wie JBoss 4 mit XML-Dateien. Sie müssen sicherstellen, dass alle Ihre XML-Implementierungsdeskriptordateien gültig sind. Möglicherweise verwenden Sie in einigen Dateien DTDs. Ich empfehle ein Upgrade, um stattdessen das XML-Schema zu verwenden.
  • Einige Bibliotheken können Inkompatibilitäten verursachen. Dies kann insbesondere zutreffen, wenn Sie auf Webdienste zugreifen und/oder XML-Analyse durchführen
  • Wenn Sie Ihre JSPs in JBoss 4 vorkompilieren, ist dies in JBoss 6/7 wahrscheinlich nicht möglich.
  • JBoss 4 und 5 verwenden unterschiedliche Implementierungen für die Nachrichtenwarteschlange. Wenn Sie Nachrichtenwarteschlangen oder Themen definiert haben, müssen Sie diese neu definieren.
  • JBoss TreeCache wird nicht mehr verwendet. Wenn Sie dies zum Zwischenspeichern verwenden, müssen Sie stattdessen den neuen JBoss-Cache verwenden.
  • JBoss 5-Sicherheit ist anders. Wenn Ihre Remote-Clients einen gesicherten Zugriff auf JBoss benötigen, müssen Sie sie anders konfigurieren.

Einige nützliche Ressourcen sind:

http://Java.dzone.com/articles/migrating-jboss-4-jboss-5http://venugopaal.wordpress.com/2009/02/02/jboss405- to-jboss-5ga

Offiziell ist JBoss 6 nur für das Java EE-Webprofil zertifiziert. Wenn Sie "ältere" Funktionen wie EJB 2.x verwenden, werden diese in Zukunft möglicherweise nicht mehr unterstützt. Abhängig vom Lebenszyklus Ihrer Anwendung kann dies ein Problem sein oder nicht. JBoss 6 unterstützt EJB2.1 derzeit vollständig, ist jedoch nicht dafür zertifiziert.

Ich habe auch festgestellt, dass JBoss 5 Speicher viel besser verarbeitet als JBoss 4. Mit JBoss 4 sehe ich viel mehr PermGen-Fehler als mit JBoss 5.

24
Dave

Ich kann nur aus Produktionserfahrungen mit JBoss 5.1.0 und einigen Untersuchungen der Version 6 sprechen.

JBoss 5 ist Java EE 5 und JBoss 6 und 7 sind Java EE 6 . Die Unterschiede in den API-Funktionen werden am besten in diesen Spezifikationen dokumentiert. JBoss 6 hat wahrscheinlich eine sehr kurze Haltbarkeit. Es ist nur für das Java EE 6-Webprofil zertifiziert und Bugfixes werden auf Version 7 (in der 3. Beta zum Zeitpunkt des Schreibens) gerichtet.

Ich denke, Sie würden im JBoss-Community-Forum bessere Antworten erhalten.

9
McDowell

Wir haben ein Upgrade von JBoss AS 5 auf JBoss AS 7 durchgeführt und streben nach WildFly AS 8.1. Momentan können wir nicht zu 8 migrieren, da es keine JMS 2-RAR der MQ-Serie gibt.

Einige Unterschiede:

  • Die Konfiguration ist so viel besser und einfacher. Es ist nicht mehr auf 20 XML-Dateien verteilt, in denen Sie Aspekte in XML-Dateien konfigurieren. Stattdessen ist alles ein zentraler Ort. Alle Ports sind an einer zentralen Stelle konfiguriert, es gibt keine XSL-Datei mehr, die server.xml transformiert. Sie können die Konfigurationsdatei verstehen, ohne die Implementierungsdetails von Klassen zu kennen. Es ist schwer zu verstehen, wenn Sie noch nie einen JBoss 5.x konfiguriert haben.
  • Das Klassenlademodell sieht gesund aus und Sie erhalten viel Kontrolle über jboss-deploy-structure.xml
  • Die zentrale Protokollierung (Slf4j, JUL, JCL, Log4j, ...) ist wirklich schön.
  • Die EJB-Client-Bibliothek sieht viel aufgeräumt aus. Es sind 10 JARs von 20, die Hälfte davon sind sogar OSGi-Bundles (unser Client ist eine Eclipse-RCP-Anwendung).
  • Das EJB-Client-Maven-Abhängigkeits-Durcheinander ist weg, stattdessen erhalten Sie jetzt ein BOM POM.
  • Sie erhalten ein Stücklisten-POM für die Server-APIs.
  • Schnellerer Start und weniger Speicherverbrauch. Wir setzen 80 EJBs und die RAR der MQ-Serie in 6 Sekunden ohne viel Abstimmungsaufwand ein. Unser Live-Datensatz liegt irgendwo über 200 MB.
  • Der Bereitstellungsordner ist standardmäßig leer
  • Die (fehlende) Qualität von XNIO ist unheimlich. In 7.x wird es nur für EJB-Remoting verwendet und wir haben mehrere Show-Stopper-Bugs (Deadlocks, Double Free, Socket-Handlecks,…) gefunden. In 8.x wird es anstelle von Tomcat auch für Servlets verwendet. Es gibt immer noch viele grundlegende Servlet-Fehler, die im Underow behoben werden.

Änderungen, die wir für unsere Bewerbung vornehmen mussten:

  • Ändern Sie die JNDI-Namen in EE 6-Standardnamen
  • migration von JBoss Cache zu Infinispan (ein Teil unseres Codes wurde zur einfachen API migriert, einige Teile verwenden immer noch die Baum-API)
  • die Sicherheit ist etwas weniger flexibel (authentifizierte und nicht authentifizierte Anrufe können nicht mehr korrigiert werden.)
  • ein schrecklicher Code, der sich auf Details der Remote-JNDI stützte
  • die Konfiguration des EJB-Clients ist unterschiedlich
  • alle Skripte zum Installieren, Bereitstellen, Starten, Stoppen usw.
  • ExternalContext ist weg, wir mussten es durch einen anderen Ansatz ersetzen
  • wir haben MBeans in SARs durch @StartUp-EJBs ersetzt
  • einige hässliche Hacks für Cocoon

Die AS 7.x-Serie enthält ein lot der Fehler, die nur in der EAP-Serie verfügbar sind. Wenn Sie mit 7.x statt mit 8.x fortfahren möchten, empfehlen wir Ihnen dringend, EAP 6 zu kaufen.

5

Hier ist ein interessanter Thread zu JBoss AS 7-Kompromissen und Zukunft, wobei auch Probleme mit AS 5 und AS 6 erwähnt werden:

http://community.jboss.org/message/613171

0
Vadzim

Ich wollte nur darauf aufmerksam machen, dass nach einem Upgrade auf das neueste möglicherweise PermGen-Aufblähungsproblem auftritt. Der JBoss-6-Mikrocontainer versucht, nach Jboss-spezifischen Anmerkungen zu suchen, indem er beim Start die Klassen aus allen JARs im Klassenpfad lädt. Dies führt dazu, dass der PermGen aufgebläht wird, sobald alle unerwünschten Klassen geladen werden. Um den Scanaufwand zu reduzieren, stellt der Mikrocontainer mithilfe von jboss-scan.xml einen weiteren Deskriptorhaken bereit. Fügen Sie diese 'jboss-scan.xml' zu WEB-INF in WARs und ass 'Jboss-Scanning hinzu .xml 'an die META-INF in den EARs.

<scanning xmlns="urn:jboss:scanning:1.0">

    <!-- Purpose: Disable scanning for annotations in contained deployment. -->

</scanning>
0
karthik m