Java EE embedded server

Z tego co wiem payara micro to nie jest single-jar, a po prostu serwer który uruchamia się tak:
java -jar payara-micro-4.1.153.jar --deploy %PATH_TO%/ spring-boot-jpa-jsf-example-1.0-SNAPSHOT.war
Co oznacza, że upraszcza deploy. Fajnie jakby zrobili single jar, ale gdyby to działało na pewno by się tym chwalili. Mnie to nie powala jak trzeba najpierw zbudować .war, a potem zrobić deploy (uruchomić AS). Pod tym względem wole spring boot albo klasyczny serwer aplikacyjny (full profile), na którym piszę się z poziomu IDE równie łatwo jak na spring boocie (dobra integracja IDE z serwerem).

Do dev i testów można szybko testować bez konfiguracji na pełnej wersji Payara (bez konfiguracji, tylko dodać lokalny serwer z NetBeans). Polecam pełną Payara po rozpakowaniu z IDE możesz robić deploy. Może się zdarzyć, że trzeba będzie wgrać sterownik JDBC na potrzeby RDBMS. Ale to w zasadzie wgranie pliku do:
C:\Java\payara-4.1.1.161.1\payara41\glassfish\domains\payaradomain\lib i tyle. Potem z poziomu web konsoli na porcie 4848 można pingnąć czy jest połączenie do datasource i to w zasadzie cała konfiguracja (dodaje się pule połączeń, a potem datasource podpięty do puli np. /jndi/mojabaza). I można pisać. Może 5 min konfiguracji. Ewentualnie na pełnej wersji warto w przypadku użycia produkcyjnego wyłączyć np. OpenMQ.

Wydaje mi się, że sensowna droga w JEE to dokeryzacja sewerów nieważne czy full profile czy web. Tu jest fajne wideo o dokerze:
http://www.adam-bien.com/roller/abien/entry/java_ee_7_thin_wars
W to mam zamiar zainwestować swój czas, aby opanować jak zarządzać kontenerami. Wiedza uniwersalna. I raczej wygląda podobnie bez względu na to czy używamy Spring Boota czy JEE (nieważne jaki profil).

Znalazłem odpowiednik spring boota dla JEE, czyli WildFly Swarm jakby ktoś szukał. Jeszcze nie testowałem.

http://wildfly-swarm.io/generator/

Chyba nie ma odpowiednika Spring Boota dla JavaEE. Wildfly Swarm tworzy cały serwer aplikacyjny obok właściwej aplikacji, więc nie rozumiem jaki jest tego sens. Najlżejszy jest chyba TomEE, wersja 7 targetuje JEE7 ale nie jest certyfikowany
link

Z tego co widzę nie ma problemu z fat-jar w JEE.

Zadeployowałem przykładowy projekt na TomEE, całość z serwerem aplikacji ma 28 MB. Korzystałem z maven-shade-plugin.

Szczegóły:
http://tomee.apache.org/ng/advanced/shading/
Gotowiec:
https://github.com/tomitribe/50-shades-of-tomee

Co do WildFly swarm, całość po spakowaniu jar ma 39 MB.

IMO są podobieństwa do Spring Boota, bo:

• jest fat jar
• jest gotowa konfiguracja (tzn. serwer aplikacyjny)
• niestety jest mniej opcji konfiguracyjnych (application.properties), ale Java EE to proste API do typowych przypadków, które i tak pokryje 90% use-case
• WildFly swarm wspiera opcjonalne gotowe konfiguracje np. wsparcie dla Camel (co prawda przez Spring)

Zbudowałem też projekt Spring Boota:
https://github.com/spring-guides/gs-serving-web-content

Wyszło 20 MB.

pokaż @margor90 jak Ty to zrobiłeś z tym WildFly. co do TomEE sobie ogarniam teraz przykłady i wgl nie widzę jak tego embedded konfigurować. jest jakieś ApplicationComposers.run(MyApp.class, args); w tym przykładzie i nagle jakaś magia się dzieje. jakby nie mogli opisać wgl ocb wtf i co jak dodam sobie jakieś opcje konfiguracji np. polaczenie do bazki itd... gdzie są jakieś przykłady.

Co do TomEE to sobie sklonuj z GitHuba. Weź projekt ApplicationComposer Shade.

$ mvn clean package
Po zbudowaniu wystarczy:
$ java -jar target/applicationcomposer-shade-1.0-SNAPSHOT.jar

Co do WildFly użyj generatora (podlinkowany wcześniej). Pobierasz projekt w zip. Projekt ma bardzo prostą strukturę. Istotny jest ten plugin:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelVersion>4.0.0</modelVersion>
  <groupId>pl.test</groupId>
  <artifactId>demo</artifactId>
  <name>Wildfly Swarm Example</name>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>war</packaging>

  <properties>
    <version.wildfly.swarm>1.0.0.CR1</version.wildfly.swarm>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
    <failOnMissingWebXml>false</failOnMissingWebXml>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.wildfly.swarm</groupId>
        <artifactId>bom</artifactId>
        <version>${version.wildfly.swarm}</version>
        <scope>import</scope>
        <type>pom</type>
      </dependency>
    </dependencies>
  </dependencyManagement>

  <build>
    <finalName>demo</finalName>
    <plugins>
      <plugin>
        <groupId>org.wildfly.swarm</groupId>
        <artifactId>wildfly-swarm-plugin</artifactId>
        <version>${version.wildfly.swarm}</version>
        <executions>
          <execution>
            <goals>
              <goal>package</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <!-- Java EE 7 dependency -->
    <dependency>
      <groupId>javax</groupId>
      <artifactId>javaee-api</artifactId>
      <version>7.0</version>
      <scope>provided</scope>
    </dependency>
    <!-- Wildfly Swarm Fractions -->
  </dependencies>
</project>

Co do budowy:
$ mvn package
Uruchomienie:
$ java -jar target/demo-swarm.jar

Proste.

no dobra wiem, tomEE tak uruchomiłam ten no, ale tam nawet nwm bd chyba musiała poczytać, bo jakaś magia się zadziała a gdzie wgl można ustawić port i OCB?

mnie to wkurza, że zrobili oni coś takiego np:
https://github.com/payara/Payara/wiki/Payara-Micro-(Payara-4.1.152.1)

a ku**** co mi po tym, że "programmaticaly" użyję sobie tego, że podam ścieżkę do wara XDDDDD.
jakby nie mogli zrobić żeby ten serwerek embeded zdeployował projekt w którym jest a nie jakiegoś tam wara. wgl na co to to ja nwm.
może nauczyli się tego maven shade plugin, napisali wrappera glassfisha i oo patrzcie wszyscy payara micro. można programmaticaly deployować wara XD.

chyba jednak czas przekonać mi się do jakiegoś normalnego serwera i tam deployować. dobrze jakby łapał hotplug zmiany w kodzie z debuga i zmiany w xhtmlkach.
nwm słyszałam o :
jboss, payara full, glassfish i wildfly.
nwm który lekki, szybki i dobry. chodzi mi pod development żeby to był szybki ziom

Wybitny Krawiec napisał(a):

Chyba nie ma odpowiednika Spring Boota dla JavaEE. Wildfly Swarm tworzy cały serwer aplikacyjny obok właściwej aplikacji, więc nie rozumiem jaki jest tego sens. Najlżejszy jest chyba TomEE, wersja 7 targetuje JEE7 ale nie jest certyfikowany
link

Nic bardziej mylnego. WildFly Swarm pakuje do uber-jara te zależności, które wykorzystujesz w projekcie (tzw. "fractions"). Jeśli korzystasz z JAX-RS to w uber-jarze znajdzie się JAX-RS, natomiast nie będzie tam niewykorzystywanych zależności np. JPA.

Pojawiły się wątpliwości odnośnie konfiguracji TomEE.

Znalazłem artytkuł, który tłumaczy takie rzeczy jak ustawienie numerów portów czy jak skonfugorować ApplicationComposer.
http://www.tomitribe.com/blog/2015/03/50-shades-of-tomee/

Pojawiła się instrukcja jak zbudować Uber jar za pomocą Payara Micro i Apache Maven Shade Plugin + jak zdokeryzować instalację:
http://blog.payara.fish/creating-uber-jar-with-payara-micro?utm_campaign=Payara%20New%20Releases&utm_content=29981776&utm_medium=social&utm_source=linkedin

Marszal napisał(a):

Wybitny Krawiec napisał(a):

Chyba nie ma odpowiednika Spring Boota dla JavaEE. Wildfly Swarm tworzy cały serwer aplikacyjny obok właściwej aplikacji, więc nie rozumiem jaki jest tego sens. Najlżejszy jest chyba TomEE, wersja 7 targetuje JEE7 ale nie jest certyfikowany
link

Nic bardziej mylnego. WildFly Swarm pakuje do uber-jara te zależności, które wykorzystujesz w projekcie (tzw. "fractions"). Jeśli korzystasz z JAX-RS to w uber-jarze znajdzie się JAX-RS, natomiast nie będzie tam niewykorzystywanych zależności np. JPA.

Ok, chyba rozumiem, tylko czemu po wybraniu samego JAX-RS + CDI pliki tyle ważą:

• demo.war 15MB
• demo-swarm.jar 100MB

Raczej spodziewałbym się, że mój uber-jar będzie miał 15MB

o @margor90 to super. zwłaszcza z tym maven'em. jakoś mi się może uda skleić to z intellij idea żeby mi się uruchamiało przez start. pytanie jeszcze tylko czy payara micro obsługuje
reload xhtmlek i podczas debuga hot plug zmienoinego kodu wiesz.

btw nadal brakuje do ideału jeszcze, ale to już jakiś krok na przód jest.

PS2: wiesz, że:
360 = 3 + 6 + 0 = 9
180 = 1 + 8 + 0 = 9
90 = 9 + 0 + 9
45 = 4 + 5 = 9
22.5 = 2 + 2 + 5 = 9
11.25 = 1 + 1 + 2 + 5 = 9

1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36 = 3 + 6 = 9
9 + 1 = 10 = 1 + 0 = 1
9 + 2 = 11 = 1 + 1 = 2
9 + 3 = 12 = 1 + 2 = 3

co się dzieje?!!!! czemu tak jest ?!!

Ostatnio wpadłem na coś takiego, ale to dopiero wczesna alfa:
http://www.next-presso.com/2016/06/meet-swarmic-the-cdi-stack/

gdzie wgl znajde źródła tego payara micro? chce sobie wejść do maina i normalnie zrobić co potrzebuje a nie oni to kurde zrobili tak bardziewnie. wgl przydałby się jakiś mikro prosty serwerek fajny na wzór spring boota. nawet olać EJB niech będzie samo CDI , które od JavaEE7 wspiera te @Transactional

Adam Bien chyba sugeruje Java EE, dockery i serwery aplikacji jak wildfly albo payara.
Czemu nie fat jary?

https://microprofile.io/

Obydwa rozwiązania (thin wars vs fat jars) mają swoje zalety i wady. Zaletą małych warek jest m.in. szybkość deployowania oraz mały rozmiar zaś wadą jest konieczność użycia serwera aplikacyjnego. Zaletą fat jarów jest proste użycie, ale wadą jest ich duży rozmiar.

spędziłam nad tym trochę czasu i szczerze dawałam szansę tym ww wyżej stosom. niestety jak dla mnie Spring Boot miażdży powyższe

@karolinaa poogladaj troche Adama Biena albo przesledz bloga.
Java EE i dockery sa calkiem ok. I mozna zachowac brak magii w kodzie. Co jednak spring troche tego doklada.

JAX-RS jest dla mnie duzo lepsze niz to co ma spring.

Spring dev tools to nie jrebel. To restartuje springa. A nie tylko podmienia zmiany ;)

@margor90 lekki serwer to ma golang :P