Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: anonym 21. 07. 2018, 21:07:20
-
Co bylo špatného na tom, mít Spring deploynutý na externím Tomcatovi, že zabudovali server dovnitř?
Musel jsem si Spring Boot Starter předělat na externí Tomcat, protože potřebuju na vzdálený server deployovat svoji aplikaci. Jenže zabalené Jarko má 40MB a trvá mi to desítky sekund než ho na server překopíruju. Když udělám chybu v kódu, čeká mě celé kolečko znova.
(Ne, nezabiju kvůli tomu týden abych postavil CI kvůli takové prkotině)
Proto jsem se rozhodl pro starou dobrou variantu, že budu deployovat na externí Tomcat a pro vzdálený server budu používat Remote deploy v IDEčku (na externí remote Tomcat). Jako bonus je zde možnost, že budu moct vlastně vyvíjet přímo na tom serveru.
Tak jsem si předělal projekt na externí Tomcat a začaly problémy, se kterýma jsem zabil celou sobotu. Do této chvíle jsem v podstatě nebyl schopný rozchodit "Reload classes and resources" tak, aby si je Spring znova načetl (používám zatím lokálně spuštěný Tomcat). Takže když upravím HTML, tak prostě musím reloadnout celou aplikaci, což trvá dost dlouho.
A tak tady sedím nad zabitou sobotou, kterou jsou promarnil rozbitým/překomplikovaným systémem a říkám si... No raději nic, nebo budu označen za trola. Prostě jsem si jen udělal zářez na futrech po kolikáté mě už ten Spring enviroment v životě zradil.
-
A proc to proste nevyvines lokalne a pak nenasadis jednou?
-
A jinak pokud chces deployovat na remote server, tak je celkem blbost pouzivat Spring Boot, muzes rovnou vyvijet WAR projekt a nahrat jako soubor na Tomcat.
-
Tohle neni prostředí pro blbce. Pokud nečteš dokumentaci a myslíš, že to funguje podle tvých hloupých představ, tak to máš smůlu. I kdybys tomu dal roky podobného zkoušení, tak ti to nebude fungovat. Zkus Python nebo Javascript, tam podobní blbci uspějí a ještě si to chválí.
-
Zkus Python nebo Javascript, tam podobní blbci uspějí a ještě si to chválí.
už zkusil
https://forum.root.cz/index.php?topic=19002.0
https://forum.root.cz/index.php?topic=19001.0
https://forum.root.cz/index.php?topic=18915.0
-
Vidím, že i tam se mu dařilo podobně ;D
-
Na Springu se vůbec nic nezměnilo, vytvořit WAR a nadeployovat ho na server můžete pořád stejně, jako dříve. Akorát se Spring Bootem máte navíc možnost používat i embedded server, což se hodí hlavně při vývoji, případně pro jednoduchou aplikaci, kde se nechcete starat o aplikační server.
-
Na Springu se vůbec nic nezměnilo, vytvořit WAR a nadeployovat ho na server můžete pořád stejně, jako dříve. Akorát se Spring Bootem máte navíc možnost používat i embedded server, což se hodí hlavně při vývoji, případně pro jednoduchou aplikaci, kde se nechcete starat o aplikační server.
Proc jen na ty male? V Boot relativne nic nechybi, jen clovek musi udelat konfiguraci pro veci, ktere nejsou out of the box (coz by musel i na Springu v WAR)
-
... A DÍKY TOME JSME TÉ MRDCE MOHL VĚNOVAT CELOU SPIČENOU SOBOTU! Z-K-U-R-V-I-S-I-N-I Z-A-M-R-D-A-N-Í"!!!!
Takže závěr je který ?
1) Informace nebyla v dokumentaci => nekvalitní dokumentace
2) Nebo jsi dokumentaci nečetl => jsi líný
-
Proc jen na ty male? V Boot relativne nic nechybi, jen clovek musi udelat konfiguraci pro veci, ktere nejsou out of the box (coz by musel i na Springu v WAR)
U větších projektů nejde o ten Spring Boot, ale o aplikační server – pro složitější aplikaci možná budete chtít více služeb aplikačního serveru, než poskytuje Jetty nebo Tomcat, a použijete třeba Wildfly nebo WebLogic, možná v clusteru.
-
Ty jsi tak strašně chytrý, to jsem fakt nevěděl že můžu lokálně použít Spring Boot s embedded jettym a pak to jako píča zbuildit do WARka a deploynout na remote, fakt díky.
To je přesně, jak jsi to měl dělat.
A když budu vyvíjet více než 1 komponentu lokálně, tak se můžu jít asi oběsit, protože píča Spring Boot zabere vždy 1 port, kdežto na remote serveru se service odlišují nikoliv porty, ale prefixy před url, takže to budu musel nějak napasovat do konfiguráků. Nádhera.
Pokud ti dělá problém i takováhle trivialita, tak bys opravdu měl raději zkusit hledat štěstí v jiném oboru, více přiměřeném tvým mentálním schopnostem.
-
Závěr je takový, že
<artifactId>spring-boot-maven-plugin</artifactId>
Excludne Devtools při buildu, pokud se builduje artefakt se všemi závislostmi. To se dá obejít přes
<excludeDevtools>false</excludeDevtools>
Ale tato píčovina nefunguje ve verzi Spring parrentu 2.0.2.RELEASE, protože prostě magic.
Funguje nicméně ve verzi 2.0.3.RELEASE a i do WARka přibalí devtools.
AVŠAK ani potom se devtools v Tomcatovi neaktivují a to ani přes přepínač:
System.setProperty("spring.devtools.restart.enabled", "true");
Takže viděl bych to tak, že pokud na tomhle vymrdaném magic chování které vymyslel nějaký hipsterský čurák nechci zabít další týden, tak si to prostě na lokální tomcat přes devtools nedeploynu.
Navíc při konverzi Spring Boot aplikace pro deploy na Tomcat se posere konfigurace pro Thymeleaf a už to dále nedokáže resolvnout template htmlka. Odhaduju, že bych na téhle chybě mohl zabít dalších několik zamrdaných dní.
Error resolving template "index.html", template might not exist or might not be accessible by any of the configured Template Resolvers
Tahleta Spring sračka je dobrá tak akorát někde do korporací, kde nikoho nesere, že bude týden nebo dva s lupou hledat, kde se co v konfiguraci posralo. Eventuálně je to dobré pro hloupého lopatoida, který nějak polepí dohromady výsledek z toho, co dům dal.
A teď z vašich reakcí nevím, jestli jsem tak blbej nebo jste tak blbí vy, já mám IQ 130, tak asi to prostě na rozuzlení těhletěch píčovin není dost a moje inteligence mi radí, abych z téhle hipsterské žumpy co nejdříve vypadl někam jinak. Spring vznikl pro nýmandské korporáty, protože ty problémy co s ním jsou jsou pořád menší, než ty, které by si nýmandi z těch korporátů udělali sami, kdyby žádný framework neměli.
Aplikační kontext pro IoC si můžu (musím) udělat sám a nepotřebuju na to zasraný a ještě navíc pomalý Spring, který potřebuje zasrané magic Devtools aby tak nějak alespoň trochu rychle nastartoval. Co na tom že je to magic, při kterém hrozí že se nějaká už inicializovaná konfigurace rozbije, protože Mr. hipster na něco zapoměl. Spring MVC patří do minulého století, protože se stejně dneska už templatuje na frontendu. Na Servletový kotejner nepotřebuju zasraný Spring. Na práci s databází nepotřebuju zasrané magic Spring Data JPA ani Hibernate, stejně mě to pak akorát sere.
Naco dpc. potrebuju, aby nejaky polofunkcni framework mi automatizoval v REST metodě konverzi z XMLka na Objekt, když mi stačí udělat:
public Response spicenySoap(String xml) {
SpicenyObjekt o = ZkonvertujToDpcNaJednomRadkuKurva.ted<SpicenyObjekt>(SpicenyObjekt.class, xml);
}
Na tohle potrebuju kurva hipstersky framework s nejakym spicenym magicem, kvuli ktereho startuje hodinu a jeste navic blbe???????????
-
A teď z vašich reakcí nevím, jestli jsem tak blbej nebo jste tak blbí vy, já mám IQ 130, tak asi to prostě na rozuzlení těhletěch píčovin není dost a moje inteligence mi radí, abych z téhle hipsterské žumpy co nejdříve vypadl někam jinak.
Tak 130 je docela málo na vývoj. Ale pokud by sis přečetl dokumentaci, tak bys problémy neměl. Chce to nebýt lempl, který chce vše zadarmo.
-
Tak nevím - je to jenom nějaká móda, nebo je to příklad těch "mileniálů" o kterých se tolik mluví v americké konzervativní propagandě?
Za mých mladých let bývalo zvykem že člověk buď držel hubu, nebo případně někam napsal článek na téma "chybami se člověk učí" (později se tomu začalo říkat "blog"). Tento týden uč čtu třetí tirádu kde ze sebe někdo vehementně dělá pitomce.
Ačkoliv to tu již několikrát padlo, tak zdůrazním: je rozdíl mezi Spring a Spring Boot, to druhé obsahuje navíc spoustu přibalených věcí a HODNĚ magie zajišťující že to jede samo hned bez konfigurace. Samotný Spring nic takového samozřejmě neobsahuje. To že tazatel vůbec o tomto rozdílu neví znamená, že se nenamáhal vůbec číst základní dokumentaci.
Druhá věc pak je, že evidentně plně nechápe všechny implikace celého konceptu Spring Boot (tj. automatická konfigurace plná magie). Jenomže to holt vyžaduje zkušenosti, tady prostě IQ nestačí.
TLDR: Samotné IQ rozhodně nestačí!!! Potřebujete zkušenosti, zkušenosti, znalosti, talent a zkušenosti. A to platí všude!
-
Tak nevím - je to jenom nějaká móda, nebo je to příklad těch "mileniálů" o kterých se tolik mluví v americké konzervativní propagandě?
Za mých mladých let bývalo zvykem že člověk buď držel hubu, nebo případně někam napsal článek na téma "chybami se člověk učí" (později se tomu začalo říkat "blog"). Tento týden uč čtu třetí tirádu kde ze sebe někdo vehementně dělá pitomce.
Ačkoliv to tu již několikrát padlo, tak zdůrazním: je rozdíl mezi Spring a Spring Boot, to druhé obsahuje navíc spoustu přibalených věcí a HODNĚ magie zajišťující že to jede samo hned bez konfigurace. Samotný Spring nic takového samozřejmě neobsahuje. To že tazatel vůbec o tomto rozdílu neví znamená, že se nenamáhal vůbec číst základní dokumentaci.
Druhá věc pak je, že evidentně plně nechápe všechny implikace celého konceptu Spring Boot (tj. automatická konfigurace plná magie). Jenomže to holt vyžaduje zkušenosti, tady prostě IQ nestačí.
TLDR: Samotné IQ rozhodně nestačí!!! Potřebujete zkušenosti, zkušenosti, znalosti, talent a zkušenosti. A to platí všude!
A za mých mladých let platilo, že nebyla k dispozici jediná varianta softwaru z JZD Slušovice a když to člověk neuměl, tak pokorně svěsil hlavu s "chybama se člověk učí". Za mě, když byl nějaký software sračka, tak šel prostě do hajzlu a vzal se lepší, protože prostě byl! Protože není jenom svět a Spring. Já jsem teda zažil super fungující magic framework a ten se jmenoval .NET. Ten byl sice taky magic, ale ten MAGIC DPČ byl dotažený do konce! Kdyby tady byl na tom světě jenom Spring a já ho neuměl, tak držím pokorně hubu, učím se a vrtám se v tom. ALE NEBUDETE TOMU VĚŘIT, dneska existují věci které prostě FUNGUJÍ (.NET), protože je nepsala na hromádce o víkendech banda hipsterů!
Další věc je, že nejsem ani náhodou sám:
http://samatkinson.com/why-i-hate-spring/
To je asi taky nějaký mileniál, běž mu to tam napsat.
Co se týče Springu, tak to mi ukaž, kdo bude dpč ručně se Springem konfigurovat ty technologie a nepoužije Spring Boot! To už za času XML konfigurace to byl porod naprosto neskutečný něco vždycky v tom hnoji rozchodit. Pak to celé zaobalí do Boot Starterů a stejně jim to blbečkům nefunguje, protože to jde sice automaticky, ale člověk o to více času stráví na tom rozřešit v te magii nějakou chybu.
-
Tak proc nepouzivas .NET? Vsak .NET Core existuje i na Linuxu :-)
> tak to mi ukaž, kdo bude dpč ručně se Springem konfigurovat ty technologie
Dle me zkusenosti tak pulka projektu ve Springu.
Na Springu se vůbec nic nezměnilo, vytvořit WAR a nadeployovat ho na server můžete pořád stejně, jako dříve. Akorát se Spring Bootem máte navíc možnost používat i embedded server, což se hodí hlavně při vývoji, případně pro jednoduchou aplikaci, kde se nechcete starat o aplikační server.
Souhlasim, spousta veci je u slozitejsich projektu jednodussi v EE - messaging, XA transakce, clustering etc. Ono se to samozrejme vse da udelat v Springu, ale v EE (Wildfly) je to jednodussi a vice unified. Nevyhodou je samozrejme to, ze to nenabizi takovou customizaci jako Spring.
-
Tak proc nepouzivas .NET? Vsak .NET Core existuje i na Linuxu :-)
> tak to mi ukaž, kdo bude dpč ručně se Springem konfigurovat ty technologie
Dle me zkusenosti tak pulka projektu ve Springu.
Na Springu se vůbec nic nezměnilo, vytvořit WAR a nadeployovat ho na server můžete pořád stejně, jako dříve. Akorát se Spring Bootem máte navíc možnost používat i embedded server, což se hodí hlavně při vývoji, případně pro jednoduchou aplikaci, kde se nechcete starat o aplikační server.
Souhlasim, spousta veci je u slozitejsich projektu jednodussi v EE - messaging, XA transakce, clustering etc. Ono se to samozrejme vse da udelat v Springu, ale v EE (Wildfly) je to jednodussi a vice unified. Nevyhodou je samozrejme to, ze to nenabizi takovou customizaci jako Spring.
Pulka projektu před Spring Bootem nebo po něm?
-
Pulka projektu před Spring Bootem nebo po něm?
Ani jedno. Projekty z/na Spring Boot nemigruji (rozhodne ne bezne), neni k tomu vubec zadny duvod totiz.
Bud chci:
* Standalone JAR / mikrosluzbu a convenience over configuration -> Spring Boot
* WAR, plnou kontrolu nad konfiguraci, deploy War na Tomcat/AS -> klasicky Spring
-
Že jste si vybral technologii, kterou neumíte používat a která možná ani není vhodná na váš projekt, to není chyba té technologie.
-
Na tohle potrebuju kurva hipstersky framework s nejakym spicenym magicem, kvuli ktereho startuje hodinu a jeste navic blbe???????????
Já se Springu nezastávám, taky to považuji za sračku(nekompatibilní kód mezi verzemi, přesuny package v libkách mezi verzemi, bugy, nekvalitní dokumentace, prakticky nemá žádný přínos a vše se bez něj dá zvládnout čistě Javou ale pracněji, apod.) Springu se vyhýbám jak čert kříži.
U těchto frameworku prostě není moc chytré(zodpovědné) přecházet mezi verzemi či je využívat bez hlubokého proniknutí do jejich problematiky.
-
Pulka projektu před Spring Bootem nebo po něm?
Ani jedno. Projekty z/na Spring Boot nemigruji (rozhodne ne bezne), neni k tomu vubec zadny duvod totiz.
Bud chci:
* Standalone JAR / mikrosluzbu a convenience over configuration -> Spring Boot
* WAR, plnou kontrolu nad konfiguraci, deploy War na Tomcat/AS -> klasicky Spring
Tak to bych řekl že s tím tolik neděláš, protože jinak bysis všiml, že Pivotal pálí za těma staršíma verzema vždy mosty. Není nic jako klasický Spring s XML, je prostě jen nová verze Springu a stará verze Springu.
-
Že jste si vybral technologii, kterou neumíte používat a která možná ani není vhodná na váš projekt, to není chyba té technologie.
Ty jsi snad přišel z JZD Slušovice nebo co. Proč by neměla být vhodná pro můj projekt DPČ?????? Protože je to sračka co se furt sere a čas to řešit mají jenom v korporátu? proto jsem si vybral špatnou technologii pro můj projekt? Já s tím Springem dozadeke dělám už 4 roky!!! Ty vole Jirskák otevři oči dozadeke a jdi se podívat jak jim to šlape v .NET, ten použiješ tak jak je ať děláš něco malého, anebo velkého, protože to PROSTĚ FUNGUJE! Ty jsi jak z jinačí planety dpč.
-
Že jste si vybral technologii, kterou neumíte používat a která možná ani není vhodná na váš projekt, to není chyba té technologie.
Ty jsi snad přišel z JZD Slušovice nebo co. Proč by neměla být vhodná pro můj projekt DPČ?????? Protože je to sračka co se furt sere a čas to řešit mají jenom v korporátu? proto jsem si vybral špatnou technologii pro můj projekt? Já s tím Springem dozadeke dělám už 4 roky!!! Ty vole Jirskák otevři oči dozadeke a jdi se podívat jak jim to šlape v .NET, ten použiješ tak jak je ať děláš něco malého, anebo velkého, protože to PROSTĚ FUNGUJE! Ty jsi jak z jinačí planety dpč.
Už ses dostatečně projevil, nemusíš se v tom ještě rozpatlávat..
-
Já s tím Springem dozadeke dělám už 4 roky!!!
Tos ale teda s těma znalostma moc nepokročil... ;D ::)
-
Že jste si vybral technologii, kterou neumíte používat a která možná ani není vhodná na váš projekt, to není chyba té technologie.
Ty jsi snad přišel z JZD Slušovice nebo co. Proč by neměla být vhodná pro můj projekt DPČ?????? Protože je to sračka co se furt sere a čas to řešit mají jenom v korporátu? proto jsem si vybral špatnou technologii pro můj projekt? Já s tím Springem dozadeke dělám už 4 roky!!! Ty vole Jirskák otevři oči dozadeke a jdi se podívat jak jim to šlape v .NET, ten použiješ tak jak je ať děláš něco malého, anebo velkého, protože to PROSTĚ FUNGUJE! Ty jsi jak z jinačí planety dpč.
Jirsáka nemám rád, ale teraz sa ho musím zastať. Spring boot je nástroj vhodný na rýchly vývoj a deployovanie webservisov, ktoré bežia na embedded webserveri. Dá sa to použiť aj na všeličo iné, ale potom je to "rovnák na ohejbák", ako na root.cz niekto poznamenal.
-
Ten Spring to má všechno tak dobře udělané, že snad budu psát i obyčejné ne-webové aplikace ve Springu. Protože to je fakt superní framework.
-
Tak to bych řekl že s tím tolik neděláš, protože jinak bysis všiml, že Pivotal pálí za těma staršíma verzema vždy mosty. Není nic jako klasický Spring s XML, je prostě jen nová verze Springu a stará verze Springu.
Ze je nova a stara verze Springu je pravda, nicmene ta aktualni verze Springu je plne podporovana i bez Bootu, vysledkem je normalni WAR.
A v podstate presne tak je udelany Boot, Spring Core + dalsi Spring knihovny (ktere si muzes do WAR projektu pridat uplne stejne) + embedded server.
Spring Boot je jen predkonfigurovane prostredi, spoustu projektu vyuzivajicich Spring ho nepouziva.
-
Co bylo špatného na tom, mít Spring deploynutý na externím Tomcatovi, že zabudovali server dovnitř?
Musel jsem si Spring Boot Starter předělat na externí Tomcat, protože potřebuju na vzdálený server deployovat svoji aplikaci. Jenže zabalené Jarko má 40MB a trvá mi to desítky sekund než ho na server překopíruju. Když udělám chybu v kódu, čeká mě celé kolečko znova.
(Ne, nezabiju kvůli tomu týden abych postavil CI kvůli takové prkotině)
Proto jsem se rozhodl pro starou dobrou variantu, že budu deployovat na externí Tomcat a pro vzdálený server budu používat Remote deploy v IDEčku (na externí remote Tomcat). Jako bonus je zde možnost, že budu moct vlastně vyvíjet přímo na tom serveru.
Tak jsem si předělal projekt na externí Tomcat a začaly problémy, se kterýma jsem zabil celou sobotu. Do této chvíle jsem v podstatě nebyl schopný rozchodit "Reload classes and resources" tak, aby si je Spring znova načetl (používám zatím lokálně spuštěný Tomcat). Takže když upravím HTML, tak prostě musím reloadnout celou aplikaci, což trvá dost dlouho.
A tak tady sedím nad zabitou sobotou, kterou jsou promarnil rozbitým/překomplikovaným systémem a říkám si... No raději nic, nebo budu označen za trola. Prostě jsem si jen udělal zářez na futrech po kolikáté mě už ten Spring enviroment v životě zradil.
A to si predstavte, ze v Spring 5 (potazmo Spring Boot 2) nemusite pouzivat servletovy container vobec a ist rovno cez Netty (a.k.a pure WebFlux).
Skoda len, ze sa nestihli lahke vlakna do JVMka a nateraz zavladli reaktivne frameworky a la RxJava a reactor. Na tomto si Pivotal pekne hreje polievocku svojho sice open source ale de facto proprietarneho Spring stacku.
Ale zase pred par rokmi len malokto veril, ze budu lambdy. Tak dufam, ze to Oracle nepo*ere, nebude hadzat chalanom polena pod nohy a dobusia tie lahke vlakna uz tento rok - debugovat a citat stack trace-y z RxJavy nikdy nebola zabava. reactor je na tom mozno o kusok lepsie, ale tiez to nie je ziadna slava.
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Kez by to byla generacni zalezitost, to by clovek alespon vedel, ze ta predchozi byla lepsi...
Ne, bohuzel nebyla. V te i one je porad kopec trotlu, co nezvladnou zaklady, ale remcaji. Dnes je to jenom zesilene snazsi moznosti publikovat.
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Slova typu "snowflakes, slunickar, multikulti, havloid" a tak, su diagnoza :) Ak chcete, aby ludia citali dalej, tak prosim davajte si pozor na papagajovani alt right propagandy ;) Kedze topic bol zalozeny ako flame, tak to sem kludne napisem.
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
Jak jeho embedded tomcat může být malý, ještě aby nebyl, když si ho tam zabudovali! Co je ti do toho, že Tomcat tam má Jasper a další libka! Ty jsou pořád načtené na classpath a tobe to může být jedno, protože se jen realoadne tvoje appka.
Navíc bych si mohl do toho tomcatu dát napevno jarka, takže bych nemusel mezi svým PC a serverem přenášet 50MB dat a čekat minutu!
A není to profi projekt, dělám si to sám pro sebe a nepotřebuju kolem toho tancovat s CI.
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
Jak jeho embedded tomcat může být malý, ještě aby nebyl, když si ho tam zabudovali! Co je ti do toho, že Tomcat tam má Jasper a další libka! Ty jsou pořád načtené na classpath a tobe to může být jedno, protože se jen realoadne tvoje appka.
Navíc bych si mohl do toho tomcatu dát napevno jarka, takže bych nemusel mezi svým PC a serverem přenášet 50MB dat a čekat minutu!
A není to profi projekt, dělám si to sám pro sebe a nepotřebuju kolem toho tancovat s CI.
Clovek si vzdycky najde nejakou omluvu pro to to zprasit...
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
Jak jeho embedded tomcat může být malý, ještě aby nebyl, když si ho tam zabudovali! Co je ti do toho, že Tomcat tam má Jasper a další libka! Ty jsou pořád načtené na classpath a tobe to může být jedno, protože se jen realoadne tvoje appka.
Navíc bych si mohl do toho tomcatu dát napevno jarka, takže bych nemusel mezi svým PC a serverem přenášet 50MB dat a čekat minutu!
A není to profi projekt, dělám si to sám pro sebe a nepotřebuju kolem toho tancovat s CI.
Clovek si vzdycky najde nejakou omluvu pro to to zprasit...
Na tom není nic zprasené, mě Aplikační servery plně vyhovovaly! To dá rozum, že nebudu dělat 100MB jarko, když libka můžu mít na Serveru. Fuj, hnus! Navíc je to standardizační faktor, takhle si nikdo do Mavenu nenaimportuje celou Guavu která má zazipovaná 8MB jenom aby z ní použil nějakou úchylnou funkci.
Nikde není psané, že to teď už musíš vyvíjet s Embedded Tomcatem!
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
Jak jeho embedded tomcat může být malý, ještě aby nebyl, když si ho tam zabudovali! Co je ti do toho, že Tomcat tam má Jasper a další libka! Ty jsou pořád načtené na classpath a tobe to může být jedno, protože se jen realoadne tvoje appka.
Navíc bych si mohl do toho tomcatu dát napevno jarka, takže bych nemusel mezi svým PC a serverem přenášet 50MB dat a čekat minutu!
A není to profi projekt, dělám si to sám pro sebe a nepotřebuju kolem toho tancovat s CI.
Clovek si vzdycky najde nejakou omluvu pro to to zprasit...
Na tom není nic zprasené, mě Aplikační servery plně vyhovovaly! To dá rozum, že nebudu dělat 100MB jarko, když libka můžu mít na Serveru. Fuj, hnus! Navíc je to standardizační faktor, takhle si nikdo do Mavenu nenaimportuje celou Guavu která má zazipovaná 8MB jenom aby z ní použil nějakou úchylnou funkci.
Nikde není psané, že to teď už musíš vyvíjet s Embedded Tomcatem!
A ze to nema CI, protoze jsi liny, ti neprijde jako klasicky projev zprasenosti?
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
Jak jeho embedded tomcat může být malý, ještě aby nebyl, když si ho tam zabudovali! Co je ti do toho, že Tomcat tam má Jasper a další libka! Ty jsou pořád načtené na classpath a tobe to může být jedno, protože se jen realoadne tvoje appka.
Navíc bych si mohl do toho tomcatu dát napevno jarka, takže bych nemusel mezi svým PC a serverem přenášet 50MB dat a čekat minutu!
A není to profi projekt, dělám si to sám pro sebe a nepotřebuju kolem toho tancovat s CI.
Clovek si vzdycky najde nejakou omluvu pro to to zprasit...
Na tom není nic zprasené, mě Aplikační servery plně vyhovovaly! To dá rozum, že nebudu dělat 100MB jarko, když libka můžu mít na Serveru. Fuj, hnus! Navíc je to standardizační faktor, takhle si nikdo do Mavenu nenaimportuje celou Guavu která má zazipovaná 8MB jenom aby z ní použil nějakou úchylnou funkci.
Nikde není psané, že to teď už musíš vyvíjet s Embedded Tomcatem!
A ze to nema CI, protoze jsi liny, ti neprijde jako klasicky projev zprasenosti?
Ne neprijde mi jako zakladni projev zprasenosti, ze si ve svem volnem case chci neco pro zabavu udelat a nebudu kvuli toho zavadet CI!
-
Nenariekajte tu nad embeddovanym Tomcat-om - je to len spicka ladovca a nie podstata toho co Spring Boot robi. Povedal by som, ze embeddovanie Tomcatu je aktualne ten mensi problem...
V Spring 5 na vas caka reactor. Pivotal sa tvari, ze na reactor riadne vsadza a vidno to na miere integracie s reactorom medzi ostatnymi subprojektami Springu.
Som fakt zvedavy aky kvalitny kod zacne bezny Springista (rozumej wedeveloper) produkovat, ked ho posadite za reactor. A teda uz som videl kadejaku "RxJava perlu" aj od seniorov so Scala pozadim.
Ak ste si to nevsimli tak, Pivotal uz zopar rokov buduje Apple-like lockin do svojho ecosystemu. Spring 4 s SB 1 je take predjedlo. Spring 5 a SB 2 je to prave orechove: nezoberu vam len Tomcat ale aj cely thread stack a control flow... Oracle to nekontruje, resp. hasi dlh, co Jave vznikol v IoT sfere. Java EE je uz prakticky zdochlina a tudy cesta nevede.
-
Ne neprijde mi jako zakladni projev zprasenosti, ze si ve svem volnem case chci neco pro zabavu udelat a nebudu kvuli toho zavadet CI!
To je fajn, že jste se ve svém volném čase chtěl naučit používat technologii, kterou už údajně čtyři roky používáte v práci. Když se ale něco chcete naučit používat, potřebujte především pokoru, pak se o tom něco naučit (zrovna na učení má Spring dobrou dokumentaci), a pak, když vám něco nebude jasné, se na to můžete zeptat. Ale na tenhle postup byste při svém údajném IQ 130 mohl přijít sám, nemyslíte? Jenom nadávat a všem okolo dokazovat, že tomu opravdu nerozumíte a rozumět nechcete, to to není zrovna dobrý postup.
Já mám kolem sebe několik projektů používajících Spring a Spring Boot, od svých soukromých sólo projektíků pro mou potřebu po projekty, na kterých dělají desítky lidí. Některé jsou nasazené na produkci s embedded Jetty, některé jsou nadeployované jako WARko na Jetty (je tam několik Spring Boot WARek a několik WARek s jinými technologiemi, než Spring), některé jsou nasazené na WebLogicu, na Wildfly, kolegové myslím používají i Tomcat. A všude to funguje, přičemž rozchození nebylo nikdy nijak obtížné – vždy to odpovídalo tomu, zda chci nějaké standardní řešení, nebo něco nestandardního. Takže pokud jsou pravdivé vaše „stesky“ na to, jak vám nic nefunguje a se vším máte problém, vychází mi z toho jediné – že je u vás problém mezi židlí a klávesnicí.
-
Zajimave, souhlasim s predrecnikem, ze nova snowflakes generace to dosahla az k presvedceni, ze za jeji vlastni blbost muze nekdo jiny, komedie.
Chlap se tu vzteka, ze si Spring Boot sam bali a sestavuje Tomcat...
Duvodem je to, ze Spring se snazi byt maly, tudiz jeho na miru sestaveny Tomcat napriklad defaultne ani neobsahuje Jasper, tedy neumi JSP a JSTL - pak muze na mem Notebooku startovat macata web aplikace 5 sekund, o dost rychleji, nez pouhy deploy WARu na holem Tomcatu... (Nebo Jettyne, nebo Undertow)
Pak se bezelstne prizna, ze je tupy, a ze vyviji primo na vzdalenem zeleze, kam pomoci IDE (!!!! proboha!!!) posila WARy na Tomcat deploy servicu...
Kazdy normalni clovek si projekt udela v Mavenu, namockuje vyvojove prostredi pomoci profilu, kompletni vyvoj dela lokalne a az vysledek nacpe (pomoci maven pluginu) na vzdaleny server (jiny profil), kdyz uz dela pro tak zoufalou firmu, co ani nema continuous integration typu Bamboo.
Jak jeho embedded tomcat může být malý, ještě aby nebyl, když si ho tam zabudovali! Co je ti do toho, že Tomcat tam má Jasper a další libka! Ty jsou pořád načtené na classpath a tobe to může být jedno, protože se jen realoadne tvoje appka.
Navíc bych si mohl do toho tomcatu dát napevno jarka, takže bych nemusel mezi svým PC a serverem přenášet 50MB dat a čekat minutu!
A není to profi projekt, dělám si to sám pro sebe a nepotřebuju kolem toho tancovat s CI.
Clovek si vzdycky najde nejakou omluvu pro to to zprasit...
Na tom není nic zprasené, mě Aplikační servery plně vyhovovaly! To dá rozum, že nebudu dělat 100MB jarko, když libka můžu mít na Serveru. Fuj, hnus! Navíc je to standardizační faktor, takhle si nikdo do Mavenu nenaimportuje celou Guavu která má zazipovaná 8MB jenom aby z ní použil nějakou úchylnou funkci.
Nikde není psané, že to teď už musíš vyvíjet s Embedded Tomcatem!
A ze to nema CI, protoze jsi liny, ti neprijde jako klasicky projev zprasenosti?
Ne neprijde mi jako zakladni projev zprasenosti, ze si ve svem volnem case chci neco pro zabavu udelat a nebudu kvuli toho zavadet CI!
- kdyz uz pouzivast tezkotonazni reseni na svoje hobby projekty, tak to CI zas takova zatez navic neni. Minimalne ti to brani prasit i jine veci, coz ocividne delas.
- CI je dneska vazne levne (nejen ve smyslu penez, ale i ve smyslu inteleketualni a casove narocnosti na nastaveni a urdrzbu), kdyz se podivas na sluzby typu Travis nebo GitLab Pipelines.
-
Tak, udělám to ve Spark framework, http://sparkjava.com/
Fildo Jirsáku, tam se nedívej, to nerozdýcháš. Používají tam totiž statické třídy namísto DI!
https://www.youtube.com/watch?v=o8O-KMlKwtE
-
Tak, udělám to ve Spark framework, http://sparkjava.com/
Tak schválně, za jak dlouho se tu objeví smršť nadávek, že Spark umožňuje používat embedded Jetty a vy to neumíte používat. Ale je zajímavé, jak to funguje, že jste si vybral zrovna Spark – mně se nikdy nelíbil a pořád se mu vyhýbám, protože mi připadá, že se v něm nedá programovat správně. Takže vám by mohl vyhovovat.
Jinak DI knihoven a frameworků existují tuny, pokud jste chtěl jenom to, nemusel jste používat Spring. Na druhou stranu, pokud jste chtěl Spring použít jenom jako DI , nechápu, s čím jste na tom válčil. Jinak DI Springu se mi zrovna moc nelíbí, sice už nějakou dobu umožňuje konfiguraci pomocí Java kódu, ale té historie tam je nabalené až moc. A pořád je to runtime záležitost, což je pro většinu použití zbytečné. Já teď sleduju Micronaut Framework, tam je konečně compile-time DI. Na můj vkus je tam toho ještě zbytečně moc zadrátovaného, jak se pokoušejí poskytnout to samé, co poskytuje Spring, ale vydali se správným směrem.
-
pivotal, to jeb nějaké piví programovací jazyk?
ps java,jetbrains a tomcat jsiou kurvitka do korporatu aby se obhájilo sraní se e s tím = mnoho práce=zaměstnání