Kilka pytań o narzędzia obok-javowe

Próbuję ciągle rozwijać swoje koderskie umiejętności, ale też przyszedł czas na ogarnięcie toolsów i próba zrozumienia pewnych rzeczy, które nie do końca rozumiem.

1. Maven, Git, Jenkins - czy są jakieś godne polecenia tutoriale, w których znajdę niezbędna wiedzę ? Wiem, że są książki do gita, ale czy wszystko stamtąd będzie przydatne ?
2. Jaką rolę pełnią i jak działają od środka serwery aplikacyjne i webowe jak tomcat, jetty, glassfish itd ? Dlaczego sama apka napisana w springu nie wystarczy, aby ją postawić na serwerze i aby działała ? Przecież mamy zdefiniowane endpointy w kontrolerach itd.

Pijany Programista napisał(a):

Próbuję ciągle rozwijać swoje koderskie umiejętności, ale też przyszedł czas na ogarnięcie toolsów i próba zrozumienia pewnych rzeczy, które nie do końca rozumiem.

1. Maven, Git, Jenkins - czy są jakieś godne polecenia tutoriale, w których znajdę niezbędna wiedzę ? Wiem, że są książki do gita, ale czy wszystko stamtąd będzie przydatne ?
2. Jaką rolę pełnią i jak działają od środka serwery aplikacyjne i webowe jak tomcat, jetty, glassfish itd ? Dlaczego sama apka napisana w springu nie wystarczy, aby ją postawić na serwerze i aby działała ? Przecież mamy zdefiniowane endpointy w kontrolerach itd.

2. Nie zgadzam się: przecież za pomocą Spring Boot i bodajże jednego startera można stworzyć aplikację webową z wbudowanym kontenerem (np. Jetty).

ad 2. Odnośnie serwerów aplikacji.
Zapewniają pracę:

• opsom : zamiast w jednym, prostym pliku .properties, błędów i problemów trzeba szukać w 50 XMLach,
• architektom (ą), zamiast po prostu dorzucić Jara do projektu - trzeba szukać dlaczego bean validation przestało działać na nowszej wersji i konfliktuje z jarem do logowania,
• dostawcom hardware, dzięki takiemu webspherowi - szesnaście potęznych maszyn w klastrze potrafi osiągnąć szybkość przetwarzania dostępną na jednym Rapsberry Pi (3),
• oraz gónikom - ktoś to wszystko musi zasilić,

Poza tym walka z błędami typu WELD-02143 czy WSVR0232E to zawsze kupa dobrej zabawy.

@jarekr000000: :DD

No ok, wiem, że spring boot sam sobie stawia ten serwer
Ale bardziej chciałbym się dowiedzieć zasadę działania tego, dlaczego taki jar nie może chodzić sam. Czy po prostu spring boot tak działa, że MUSI mieć tego tomcata czy co tam, czy po prostu twórcom springa nie chciało się samemu robić obsługi websocketów itd, bo z tego co rozumiem to właśnie te serwery aplikacyjne są niskopoziomową obsługą zapytań http i na to wjeżdża boot ze swoimi controllerami ?

I w ogóle jest jakaś różnica między serwerem aplikacji, a webowym ?

Nie pytaj mnie o spring boot, bo mnie on raczej bardzo nie interesuje, wystarczyh, że w jendym banku muszę się na spring boot męczyć.
Serewer http możesz postawić na gołej javie bnez żadnych bibliotek. https://javarevisited.blogspot.com/2015/06/how-to-create-http-server-in-java-serversocket-example.html

Polecam niektóre bibliotekim dzięki którym jest łatwiej i przyjemniej: Ratpack, akka-http, kotlin-ktor, Spring WebFlux.
Noe polecam po prostu servletowych frameworków , opartych o application servery (nawet embedded). Ich czas dobiegł końca.

ad 1. Książka Johna Fergusona Smarta Java Power Tools. Co prawda jest już troszkę przestarzała, ale podstawy nie zmieniają się tak szybko.
ad 2. Jest trochę jak opisuje @jarekr000000, ale też nie jest aż tak źle. Serwery aplikacyjne zapewniają infrastrukturę (middleware) oraz "ogarniają" komunikację twojej aplikacji z resztą świata. Można to oczywiście samodzielnie napisać za pomocą Ratpacka, ale trzeba tu trochę już ogarniać. Spring Boot idzie z wbudowanym Jettym więc to tylko nakładka. Pytanie czy chcesz używać rzeczy, które są wspierane w serwerach aplikacyjnych, a ich ręczne ogarnięcie może być bardzo problematyczne (SOAP, Kolejki JMS itp.).

Co zaś tyczy się problemów, to dużo zależy od tego jak używasz narzędzi. W obecnym projekcie mamy Weblogica i nie ma typowych weblogicowych problemów, za to mamy masę problemów z rozszerzeniami, które napisali twórcy Fabrica3.

@jarekr000000:
Widziałem Twoje filmy o Ratpacku i Web Fluxie. Faktycznie fajnie to wygląda bo mimo większej ilości kodu mamy większą kontrolę. Najbardziej dały mi do zrozumienia transakcje. Ostatnio ogarnąłem, że jeśli robię konfigurację beanów w springu ręcznie i wstrzykuję sobie w klasie @Configuration obiekty normalnie przez new, aby spring nimi bez sensu nie zażądzał to @Transactional nie działa, bo obiekty danej klasy nie są beanami :O .. tragedia .. dlatego chyba w następnej apce użyję tego Spring Fluxa.

@Koziołek
Dzięki. A spring boot czasem nie chodzi z tomcatem ? Przynajmniej ja dostaję logi, że tomcat wystartował coś na danym porcie, chyba, że to kwestia jakiejś konfiguracji, ale domyślnie nic nie zmieniałem. Czyli w takim razie, takie tomcaty/jetty chodzą jako osobny jar i flow przebiega tak, że idzie request do tomcata, a on to podsyła pod naszą springową apkę czy to wygląda jakoś inaczej ?

I mówisz cały czas o serwerach aplikacyjnych .. a webowe to to samo ?

Tomcat/Jetty zależy od konfiguracji. I generalnie to tak działa, że SB uruchamia serwer jako osobny proces. Co do serwerów web i aplikacyjnych, to te pierwsze trochę "umarły" właśnie przez SB. Serwery aplikacyjne są znacznie większymi rozwiązaniami, które dają znacznie więcej możliwości.

@Koziołek: co do poważnych serwerów aplikacyjnych zgadazam się z gośćmi z thoughtworks
https://www.thoughtworks.com/radar/platforms/application-servers
one powinny już wymrzeć,

• problem, który rozwiązywały zniknął
• stwarzają DUŻO więcej problemów niż rozwiązują

Dodatkowo embedded serwres to prawie taka sama kupa jak standalone,( z punku widzenia kodu), tylko debugować łatwiej i mniej problemów z classloaderami (zawsze to coś).

@jarekr000000:

Most teams we work with favor bundling an embedded http server within your** web application**.

Jak aplikacja nie jest web, albo nie masz http, to te serwery są całkiem sensownym middlewarem. Choć rzeczywiście należy wtedy jasno powiedzieć jaka jest rola takiego ASa.

@Koziołek: to może inaczej gdzie widzisz jakąkolwiek rolę dla jakiegokolwiek application serwera? Tak, żeby nie dało się tego dużo prościej zrobić bez.
Kiedyś zapewniały spójny konfig i startowanie wielu aplikacji na jednej JVM żeby oszczędzić RAM.
W czasach dockera i 128 gb RAM dla ubogich nie widze sensu.

@jarekr000000: nie zawsze masz 128GB RAM w wersji dla ubogich (patrz AIX i inne wynalazki IBMa). U nas AS pełni dwie role

1. Ogarnia SOAP Security z SAMLami
2. Pełni rolę middleware pozwalając na sensowne zarządzanie klastrem i organizacją dostępu do zasobów i usług (przez JNDI).

Można to oczywiście przepisać na coś super lekkiego, czym łatwiej się zarządza, ale klient nie ma na to zasobów. W dodatku jest tu kilka vendor locków, które powoli rozwiązujemy. Jak to ogarniemy, to będzie można myśleć o ucieczce z Weblogica.

@Koziołek zupełnie rozumiem twój przypadek. Dokładnie niedawno taki miałem. Application Serwer rozwiązuje problemy związane z tym, że macie Application Serwer (i Vendor locki). Brawo. Dlatego właśnie nie należy tego nigdzie wrzucać.
Jeszcze niedawno płakałem bo nie mogłem podbić Javy do ósemki na Websphere, a SAML token check zajmował na klastrze 95% czasu procesora (IBM miał tam ładnego buga).
(Btw. buga obeszliśmy, websphera po prawie roku prac udało się podbić do nowej wersji, która obsługiwała Javę 8mkę. O 9ce czy javie 10 to nawet nie ma co mówić :-) )

A mógł być kubernetes, JWT i w ogóle 21 wiek.

OP pytales czy musisz uzywac Tomcata. Nie musisz ale zarazem jest on standardowym serwerem.
W Spring Boot masz

dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-tomcat</artifactId>
  <version>2.0.0.RELEASE</version>
  <scope>compile</scope>
</dependency>

Z kolei Starter-Tomcat zawiera:

<dependency>
  <groupId>org.apache.tomcat.embed</groupId>
  <artifactId>tomcat-embed-core</artifactId>
  <version>8.5.23</version>
  <scope>compile</scope>
</dependency>
<dependency>
  <groupId>org.apache.tomcat.embed</groupId>
  <artifactId>tomcat-embed-el</artifactId>
  <version>8.5.23</version>
  <scope>compile</scope>
</dependency>
<dependency>
  <groupId>org.apache.tomcat.embed</groupId>
  <artifactId>tomcat-embed-websocket</artifactId>
  <version>8.5.23</version>
  <scope>compile</scope>
</dependency>

Gdy uruchamiasz aplikacje w logach wyswietla o.s.b.w.embedded.tomcat.TomcatWebServer : , ktory domyslnie startuje na porcie 8080. Tomcat jest domyslnym serwerem i mozesz sobie go zmienic na Jetty czy Undertow. Wyrzuc zaleznosci Tomcat z konfiguracji i zastap je tym:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

Dla Undertow:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

Nastepnie w application.properties mozesz sobie skonfigurowac swoj nowy 'embedded'

server.compression.enabled=false
server.context-path= 
server.display-name=application 
server.error.include-stacktrace=never 
server.error.path=/error 
server.error.whitelabel.enabled=true 
server.port=8080
server.server-header=
server.servlet-path=/ 

Wiecej opcji konfiguracyjnych tutaj: https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html