+ Antworten
Ergebnis 1 bis 8 von 8

Thema: JEE Anwendungen als Single Jar (Wildfly Swarm, Payara Micro)

  1. #1
    User Viertel Megabyte Themenstarter
    Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    364
    Genannt
    31 Post(s)
    Hi zusammen,

    hat hier eigentlich schon jemand Erfahrungen mit dem Konzept der Embedded JEE Server gesammelt? Ich spiele zur Zeit mit Wildfly Swarm herum und mir gefällt hier gerade das modulare Konzept ganz gut, dass das Maven Plugin "errät", welche Komponenten die Anwendung benötigt, das macht wirklich einen schlanken Fuß.

    Natürlich hauptsächlich für Microservices im Fokus zur Zeit, auch wenn ich für so etwas keine Anwendungsfälle habe, aber auch bei weniger technikaffinen Kunden finde ich das eine gute Lösung, einfach das Jar ausführen und glücklich sein.

    Gruß
    Tim
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

  2. #2
    Global Moderator Floppy Disc
    Registriert seit
    30.07.2013
    Fachbeiträge
    841
    Genannt
    110 Post(s)
    Zählt Tomcat auch?
    Dann ja

    Deployed wird viel einfacher IME, wenn der Container embedded wird, ein Jar ausliefen, starten, fertig
    Selbst Legacy Anwendungen profitieren davon, nicht nur "Microservices".
    Maven is never completely installed

  3. #3
    User Kilobyte Avatar von Greta
    Registriert seit
    15.08.2013
    Ort
    im Büro
    Fachbeiträge
    176
    Genannt
    32 Post(s)
    Hatte mal ein kleines Projekt das auf Sring-Boot mit Tomcat aufgebaut war. War ne kleine Anwendung für ne Messe und man sparte sich so ne Menge Zeit den Messe-PC vorzubereiten.

    War ein bisschen fricklig da JSF mit reinzubekommen, aber ging letzlich dann doch. Wenn auch leider nicht gänzlich ohne xml-Config-Dateien.
    Ich bin so klug, K L U K!!!

  4. #4
    User Kilobyte
    Registriert seit
    13.10.2015
    Fachbeiträge
    167
    Genannt
    19 Post(s)
    Punkte die mich Interessieren würden

    Dateigrösse: WAR vs Standalone-JAR. Gerade wenn man irgendwo remote deployt, dann kann es einen Unterschied machen ob man ein kleines WAR über die dünne Leitung schiebt oder ob jedes mal noch ein AS dranhängt.


    Start Zeiten: Hier käme jedes mal noch das Booten des AS hinzu, was während der Entwicklung mMn. etwas stärker ins Gewicht fällt im Gegensatz zu einem einfachen redeployment.


    Möglichkeit mehrere Anwendungen in einer JVM laufen zu lassen. Möchte man manchmal haben, braucht man aber nicht unbedingt und kann andere Probleme nach sich ziehen. Manchmal möchte man das ganze Zeug auch getrennt haben.


    Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.


    Bei einem War habe ich eher, dass Gefühl, dieses auf jedem beliebigen AS zum laufen zu bekommen während man sich beim embedden doch schon stark festlegt. Was auch wieder seine Vorteile haben kann, wie bereits genannt.

  5. #5
    Global Moderator Floppy Disc
    Registriert seit
    30.07.2013
    Fachbeiträge
    841
    Genannt
    110 Post(s)
    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Dateigrösse: WAR vs Standalone-JAR. Gerade wenn man irgendwo remote deployt, dann kann es einen Unterschied machen ob man ein kleines WAR über die dünne Leitung schiebt oder ob jedes mal noch ein AS dranhängt.
    Gute Frage, hab auf die schnelle das hier gefunden: java - Spring boot WAR size with different embedded servers - Stack Overflow
    WildFly Swarm koennte @inv_zim wohl mehr sagen.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Start Zeiten: Hier käme jedes mal noch das Booten des AS hinzu, was während der Entwicklung mMn. etwas stärker ins Gewicht fällt im Gegensatz zu einem einfachen redeployment.
    Embedded Tomcat bzw. Jetty brauchten gefuehlt nur einen Bruchteil was die normalen Container zum starten/redeployen brauchten, ist auch nicht verwunderlich wenn man bedenkt dass die embedded Varianten einiges von dem ganzen "Standard Krempel" und "Management Anwendungen" erstmal weglassen.
    Das ganze ist so 1-2 Jahre her, hab deshalb keine genauen Zeiten.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Möglichkeit mehrere Anwendungen in einer JVM laufen zu lassen. Möchte man manchmal haben, braucht man aber nicht unbedingt und kann andere Probleme nach sich ziehen. Manchmal möchte man das ganze Zeug auch getrennt haben.
    Getrennt ist einfach einfacher
    Wenn man mehrere Anwendungen in einem Container laufen laesst, dann oft nicht weil man moechte, sondern weil man muss.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.
    Das ist richtig.
    Auf der anderen Seite weiss man dafuer aber immer, dass die Tests mit der gleichen Container Version laufen wie in der Produktion, ein Grund weniger um in eine "but it works on my machine" Situation zu kommen.
    Maven is never completely installed

  6. #6
    User Viertel Megabyte Themenstarter
    Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    364
    Genannt
    31 Post(s)
    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Dateigrösse: WAR vs Standalone-JAR. Gerade wenn man irgendwo remote deployt, dann kann es einen Unterschied machen ob man ein kleines WAR über die dünne Leitung schiebt oder ob jedes mal noch ein AS dranhängt.
    Wildfly Swarm hat bei mir 90mb Overhead draufgepackt. Payara Micro liegt glaube ich bei 70. Ist schon eine Hausnummer und ein berechtigter Einwand.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Start Zeiten: Hier käme jedes mal noch das Booten des AS hinzu, was während der Entwicklung mMn. etwas stärker ins Gewicht fällt im Gegensatz zu einem einfachen redeployment.
    Nach meinen bisherigen Erkenntnissen: Wildfly Swarm wird von Maven nur in der Packaging Phase berücksichtigt, es wird auch das "normale" war erzeugt. Es sollte also möglich sein, auf einem gebooteten Wildfly zu entwickeln und es am Ende per Swarm zu paketieren.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Möglichkeit mehrere Anwendungen in einer JVM laufen zu lassen. Möchte man manchmal haben, braucht man aber nicht unbedingt und kann andere Probleme nach sich ziehen. Manchmal möchte man das ganze Zeug auch getrennt haben.
    Müsste man mit EAR Packaging so können, aber ist vielleicht für Swarm oder Micro oder Boot nicht der richtige Anwendungsfall.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.
    Korrekt.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Bei einem War habe ich eher, dass Gefühl, dieses auf jedem beliebigen AS zum laufen zu bekommen während man sich beim embedden doch schon stark festlegt. Was auch wieder seine Vorteile haben kann, wie bereits genannt.
    Da kann ich dir leider nicht so ohne weiteres zustimmen. Bestes Beispiel: Payara benutzt MoXy, Wildfly Jackson, Payara Eclipselink, Wildfly Hibernate. Das ergibt schon so viele natürliche Grenzen und imkompatibilitäten, dass es tatsächlich (meiner Meinung nach) schon mit ordentlichem Aufwand verbunden sein kann einen simplen REST Service mit Persistenz übergreifend zum Laufen zu kriegen.
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

  7. #7
    Projekt-Moderator Butterfaces Halbes Megabyte Avatar von Sym
    Registriert seit
    31.07.2013
    Fachbeiträge
    574
    Genannt
    27 Post(s)
    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Dateigrösse: WAR vs Standalone-JAR. Gerade wenn man irgendwo remote deployt, dann kann es einen Unterschied machen ob man ein kleines WAR über die dünne Leitung schiebt oder ob jedes mal noch ein AS dranhängt.
    Sowohl SpringBoot als auch Wildfly-Swarm binden nur die Dependencies ein, die auch wirklich gebraucht werden. Damit ist das jar dann natürlich immer noch größer als ein normales war aber in der Regel kleiner als ein AppServer gebundled mit einem war.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Start Zeiten: Hier käme jedes mal noch das Booten des AS hinzu, was während der Entwicklung mMn. etwas stärker ins Gewicht fällt im Gegensatz zu einem einfachen redeployment.
    Ich habe den Swarm bis CR1 aktiv verfolgt. Hier gibt es z.B. maven-Plugins, die das Starten auf einfache Art und Weise ermöglichen. Auch bei SpringBoot gibt es so etwas. Geschwindigkeitsverluste sind marginal, allerdings kommt es wohl auf die Anwendung an. Ich hatte bisher jedoch keine Probleme.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Möglichkeit mehrere Anwendungen in einer JVM laufen zu lassen. Möchte man manchmal haben, braucht man aber nicht unbedingt und kann andere Probleme nach sich ziehen. Manchmal möchte man das ganze Zeug auch getrennt haben.
    Mehrere war in einer JVM war ja ein Hauptgrund für AppServer. Ich halte von dieser Sicht nicht mehr viel. Gerade weil die meisten Server leichtgewichtig (und auch kostenlos) sind, kann man davon ohne Probleme mehrere Instanzen starten. Nachteile sehe ich da nicht. Vorteile sind jedoch, dass die Artefakte unabhängig voneinander laufen.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Version des AS ist mit der Anwendung verzahnt. Einerseits gut wegen Versionierung, andererseits muss man die Anwendung neu bauen, wenn man aus Sicherheitsgründen updaten möchte, sollte.
    Das ist ganz häufig der Fall. Gerade im JEE-Fall sind nicht immer alle APIs kompatibel. Häufig baut man für ein oder 2 Versionen des AS eine Anwendung. Wenn man dann ein Update vom AS durchführt, muss man ja häufig ebenfalls die Anwendung anpassen. Aus Betriebssicht würde ich auch sagen. dass App und AS eine Einheit bilden sollten.

    Zitat Zitat von ionutbaiu Beitrag anzeigen
    Bei einem War habe ich eher, dass Gefühl, dieses auf jedem beliebigen AS zum laufen zu bekommen während man sich beim embedden doch schon stark festlegt. Was auch wieder seine Vorteile haben kann, wie bereits genannt.
    Die Wirklichkeit ist allerdings anders. Die einzelnen JPA-Implementierungen sind nicht immer kompatibel (je nachdem, was man an Funktionalität verwendet). Das betrifft auch andere Bereiche von JEE. Ich empfinde das Bundling eher als Vorteil. Und seien wir mal ehrlich: wie oft wechselt man einen AS?
    www.butterfaces.org = JSF 2 + Bootstrap + JQuery = awesome
    https://github.com/larmic

  8. #8
    User Viertel Megabyte Themenstarter
    Avatar von inv_zim
    Registriert seit
    31.07.2013
    Ort
    Rhein-Main Gebiet
    Fachbeiträge
    364
    Genannt
    31 Post(s)
    Nachdem ich gerade wieder an einer kleinen Swarm Anwendung bin: Das Tooling gefällt mir gut. Gestartet werden kann das Ganze auch aus der IDE mit mvn wildfly-swarm:run, Änderungen an JSF Pages werden sofort per Hotswap angezeigt. Funktioniert ähnlich gut wie Spring Boot, wobei hier das Tooling beim Aufsetzen des Projekts mir noch besser gefällt. Startzeit des WAR files nach dem Kompilieren übrigens unter 2 Sekunden.
    I am obsessed with the ancient science of "puzzle-ometry". I have discovered that within puzzles lies the secret of human intelligence, that which separates us from the common beast.

+ Antworten Thema als "gelöst" markieren

Direkt antworten Direkt antworten

Welche Farbe hat im Allgemeinen das Blut von Säugetieren?

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Ähnliche Themen

  1. Antworten: 2
    Letzter Beitrag: 29.06.2015, 16:41
  2. Micro Services in Java - Brauchts das?
    Von maki im Forum Java Enterprise Edition (Java EE)
    Antworten: 12
    Letzter Beitrag: 07.01.2015, 10:27
  3. Hibernate JPA Optionales single value embeddable mit nonnull-field
    Von cmrudolph im Forum APIs & Frameworks
    Antworten: 6
    Letzter Beitrag: 01.07.2014, 14:32
  4. Single dockable in a StackableDockStation
    Von notzippy im Forum DockingFrames
    Antworten: 21
    Letzter Beitrag: 21.09.2010, 10:36
  5. Antworten: 0
    Letzter Beitrag: 19.09.2007, 07:57

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •