mboost-dp1
Servlet Containers
/rage on
Servlet Containers som en Java teknologi må være den meste dumme form for web-server type jeg nogen sinde har set.
Der findes ikke en eneste som ikke kræver en komplet restart for at kunne opdatere en simpel ændring i client-side view (HTML/Javascript/CSS), og der findes ikke et eneste IDE som kan finde ud af kun at publish dette, og derfor bliver der altid foretaget et full build af ens projekt. Derudover kommer så test problemer i forbindelse med serverside cache (som ingen servlet container tillader man kan slå fra totalt), og browser cache (som er provokerende at skulle slå fra!)
Dette er så latterligt virkelighedsforladt at jeg ikke kan forstå hvorfor sådan software stadig findes i dag.
Men mange elsker jo galskaben, så jeg tænker om der måske er nogen der kan fortælle HVORFOR dette underlige virkelighedsfjerne koncept benyttes?
Og at man kan deploy til dem med en zip fil frem for en mappe er nok det mest ligegyldige nogensinde!
Virtual Directories som der kan benyttes i forbindelse med IIS og Apache, er på enhvert plan mere logisk og mindre performance krævende end servlet containers.
Desuden gør strukturen i Servlet Containers at der åbenbart ikke kan bygges direkte IDE integration ala. ASP.NET (Det er ikke lykkeds efter 10 år, så jeg tror ikke på det kommer), og "stack trace from hell" har altså ikke fået sit navn for sjov.
Servlet Containers som en Java teknologi må være den meste dumme form for web-server type jeg nogen sinde har set.
Der findes ikke en eneste som ikke kræver en komplet restart for at kunne opdatere en simpel ændring i client-side view (HTML/Javascript/CSS), og der findes ikke et eneste IDE som kan finde ud af kun at publish dette, og derfor bliver der altid foretaget et full build af ens projekt. Derudover kommer så test problemer i forbindelse med serverside cache (som ingen servlet container tillader man kan slå fra totalt), og browser cache (som er provokerende at skulle slå fra!)
Dette er så latterligt virkelighedsforladt at jeg ikke kan forstå hvorfor sådan software stadig findes i dag.
Men mange elsker jo galskaben, så jeg tænker om der måske er nogen der kan fortælle HVORFOR dette underlige virkelighedsfjerne koncept benyttes?
Og at man kan deploy til dem med en zip fil frem for en mappe er nok det mest ligegyldige nogensinde!
Virtual Directories som der kan benyttes i forbindelse med IIS og Apache, er på enhvert plan mere logisk og mindre performance krævende end servlet containers.
Desuden gør strukturen i Servlet Containers at der åbenbart ikke kan bygges direkte IDE integration ala. ASP.NET (Det er ikke lykkeds efter 10 år, så jeg tror ikke på det kommer), og "stack trace from hell" har altså ikke fået sit navn for sjov.
Windcape (1) skrev:Der findes ikke en eneste som ikke kræver en komplet restart for at kunne opdatere en simpel ændring i client-side view (HTML/Javascript/CSS), og der findes ikke et eneste IDE som kan finde ud af kun at publish dette, og derfor bliver der altid foretaget et full build af ens projekt.
Blah blah blah...
Det virker fint for mig, så jeg vil da tro der findes løsninger, uanset hvad du siger.
Som jeg har sagt til dig så mange gange før: Jeg tester mine ændringer løbende ved at trykke CTRL-S, ALT-TAB, F5.
Og du ved med sikkerhed dit IDE ikke laver en full publish af din Java?myplacedk (2) skrev:Som jeg har sagt til dig så mange gange før: Jeg tester mine ændringer løbende ved at trykke CTRL-S, ALT-TAB, F5.
Auto-publish i Netbeans, IDEA og Eclipse laver en full publish, så medmindre du benytter ANT, er det på ingen måde hurtigere.
Jeg oplever 404 og Stack Trace from Hell ved updates pga. at browseren åbner hurtigere end der publish til servlet containeren.
Det er heldigt for dig, men det ændre jo ikke på konceptet.myplacedk (5) skrev:#4
Hvad den end gør, er den hurtigere end jeg er. Som sagt, det virker fint.
Hvis alle delte den opfatning af ting, ville vi jo stadig kode assembly i notepad-like text-editors.
Den er IKKE hurtigere end mig, og det er et problem!
#6
Vent et sekund længere, få dig en computer med mere end 512 MiB ram, eller indse at der nok er en mulighed du ikke har prøvet endnu.
Den forstod jeg ikke. Min opfatning er at der er en løsning. Din er tilsyneladende at du ved alt, og at der ingen løsning er.
Vent et sekund længere, få dig en computer med mere end 512 MiB ram, eller indse at der nok er en mulighed du ikke har prøvet endnu.
Windcape (6) skrev:Hvis alle delte den opfatning af ting, ville vi jo stadig kode assembly i notepad-like text-editors
Den forstod jeg ikke. Min opfatning er at der er en løsning. Din er tilsyneladende at du ved alt, og at der ingen løsning er.
Selv på min stationær med 4gb ram, og kraft nok til heavy gaming, er Eclipse's restart af f.eks. Tomcat langsommere end at at åbne en ny tab i Firefox.
Det jeg siger der ikke er en løsning til er hele konceptet i servlets, hvor at filerne ikke ligger fastlåst i en filstruktur (som de jo gør alligevel, hele ideen med WAR er underlig).
Det jeg siger der ikke er en løsning til er hele konceptet i servlets, hvor at filerne ikke ligger fastlåst i en filstruktur (som de jo gør alligevel, hele ideen med WAR er underlig).
#1
No offence, men du er blevet sat eftertrykkeligt på plads, før når du kommer efter en teknologi du ikke forstår.
Hvorfor ikke tage et dybt åndedræt og indse at du ikke kan forstå alt, første gang du giver den gas med en teknologi.
Der er altså kloge hoveder, du ikke bare tager ud med din første indskydelse...som sagt, no offence, men du virker temmelig påståelig eller arrogant..
No offence, men du er blevet sat eftertrykkeligt på plads, før når du kommer efter en teknologi du ikke forstår.
Hvorfor ikke tage et dybt åndedræt og indse at du ikke kan forstå alt, første gang du giver den gas med en teknologi.
Der er altså kloge hoveder, du ikke bare tager ud med din første indskydelse...som sagt, no offence, men du virker temmelig påståelig eller arrogant..
Hvorfor bliver du ved med at rode med Java når du så tydeligt hader det og er smask forelsket i ASP.NET?
Windcape (8) skrev:Selv på min stationær med 4gb ram, og kraft nok til heavy gaming, er Eclipse's restart af f.eks. Tomcat langsommere end at at åbne en ny tab i Firefox.
Så er der to løsninger tilbage ("vent et sekund" og "indse du tager fejl"). Kan du se hvor vi er på vej hen?
Windcape (8) skrev:Det jeg siger der ikke er en løsning til er hele konceptet i servlets, hvor at filerne ikke ligger fastlåst i en filstruktur (som de jo gør alligevel, hele ideen med WAR er underlig).
Det forstår jeg heller ikke. Er du ked af at holde dine filer nogenlunde organiseret?
Windcape (8) skrev:Selv på min stationær med 4gb ram, og kraft nok til heavy gaming, er Eclipse's restart af f.eks. Tomcat langsommere end at at åbne en ny tab i Firefox.
Har du ikke overvejet at lukke for din "heavy gaming" før du leger med Eclipse?
Jeg forstår ikke helt sammenhængen, mener du at det burde tage lige så lang tid at restarte og reloade en server, som det burde tage at starte en tab op i firefox?
Django opfører sig også sådan, du kan ikke ændre indstillinger mens serveren kører. Det kræver reload. Den reloader dog dine sider hvis disse ændrer sig, men det gør den vist kun hvis den er i DEBUG-mode, er den i produktion kræver det reload.
Jeg mener også PHP opfører sig sådan i nogle af dens opcode / cache extensions, men det er længe siden jeg har leget med dem.
Django opfører sig også sådan, du kan ikke ændre indstillinger mens serveren kører. Det kræver reload. Den reloader dog dine sider hvis disse ændrer sig, men det gør den vist kun hvis den er i DEBUG-mode, er den i produktion kræver det reload.
Jeg mener også PHP opfører sig sådan i nogle af dens opcode / cache extensions, men det er længe siden jeg har leget med dem.
#15
Ja, men problemet med java som udviklingsmijlø er at du ikke har et valg. SUNs ide om ikke at benytte en typisk HTTP server med et sprog specific modul, eller FastCGI (En servlet container er princippet bare et sprogmodul over fastcgi).
Jeg undre mig meget over at SUN på det eneste, har startet et nyt projekt (Glassfish), som stadigvæk følger den traditionelle udviklerfjenske struktur.
Ja, men problemet med java som udviklingsmijlø er at du ikke har et valg. SUNs ide om ikke at benytte en typisk HTTP server med et sprog specific modul, eller FastCGI (En servlet container er princippet bare et sprogmodul over fastcgi).
Jeg undre mig meget over at SUN på det eneste, har startet et nyt projekt (Glassfish), som stadigvæk følger den traditionelle udviklerfjenske struktur.
Windcape (16) skrev:Ja, men problemet med java som udviklingsmijlø er at du ikke har et valg. SUNs ide om ikke at benytte en typisk HTTP server med et sprog specific modul, eller FastCGI (En servlet container er princippet bare et sprogmodul over fastcgi).
Med den typiske servlet container har du netop et valg som du ikke har med alternativerne.
Du kan godt sammenligne en servlet engine med PHP som FastCGI eller ASP.NET worker process.
Men den typiske servlet engine giver dig som den eneste af dem et valg. Du kan gøre det samme som du gør med de andre: du kan sende requests til din web server (Apache eller IIS) og lade den kommunikere med den anden process (Tomcat understøtter AJP protokollen til dette formål). Eller du kan sende HTTP requests direkte til servlet engine.
I production vil der stort set altid være en almindelig web server foran. Typisk Apache (ofte i forklædning som IBM HTTP Server eller Oracle HTTP Server) men IIS er også set. En af pointerne er her at man kan køre --firewall--web server--firewall--app server.
For development finder man det typisk nemmest at undlade web serveren og sende HTTP requests direkte til servlet engine.
Windcape (16) skrev:Jeg undre mig meget over at SUN på det eneste, har startet et nyt projekt (Glassfish), som stadigvæk følger den traditionelle udviklerfjenske struktur.
Det er der nok flere grunde til:
1) SUN kan næppe se at det er et problem at give brugerne en valgmulighed.
2) GlassFish bruger en modificeret Tomcat som web container. Så i et eller andet omfang hænger de på Tomcat designet.
Windcape (1) skrev:Og at man kan deploy til dem med en zip fil frem for en mappe er nok det mest ligegyldige nogensinde!
Du kan og *bør* deploye som en war fil.
Det giver server implementationen frihed til at organisere sine interne data som den vil.
Der er servere som gør mere end bare udpakke ear/war/ejb jar/rar ved deployment.
Windcape (1) skrev:Virtual Directories som der kan benyttes i forbindelse med IIS og Apache, er på enhvert plan mere logisk og mindre performance krævende end servlet containers.
Virtual directories er en mapning fra URL's til applikation. Det giver ikke mening at sammenligne det med en servlet engine.
En servlet engine giver dig også mulighed for at lave en tilsvarende mapning.
For Tomcat skal du kigge på mulighderne for at definere context.
Windcape (1) skrev:og "stack trace from hell" har altså ikke fået sit navn for sjov.
Java stack traces er ligesom stack traces i alle andre compilerede sprog. ASP.NET giver lignende stack traces. Og jeg vil tro at et CGI script i C++ ville gøre det samme.
PHP er anderledes fordi PHP grundliggende er fortolket.
Windcape (4) skrev:Auto-publish i Netbeans, IDEA og Eclipse laver en full publish,
Da en file copy ikke vil virke med nogle servere og for andre servere vil kræve ændringer i server konfigurationen, så virker det ret praktisk at følge standarden og deploye en war fil.
Ikke når de handler om ikke-compileret resourcer.arne_v (19) skrev:Virtual directories er en mapning fra URL's til applikation. Det giver ikke mening at sammenligne det med en servlet engine.
At skulle re-deploy en million grafiske filer hver gang man laver en ændring i sin CSS fil er altså ikke særlig smart.
Det er netop derfor ens servlet engine kun burde håndtere compilerede resourcer, og så fortolke resten løbende, og altså være ligeglad med hvor de ligger i en fil-struktur.
#21
Nu har jeg iøvrigt prøvet at teste cache af static data. Og jeg kan slet ikke genskabe dit problem.
Standard Tomcat 6.0.18.
Standard FireFox 3.0.
Vi laver en test.txt.
Request:
Response:
Indhold hentes helt normalt.
Så prøver vi igen.
Request:
Response:
Det er jo helt som det skal være. Der er ikke ændret i filen, så browserens kopi er OK.
Vi retter i test.txt.
Request:
Response:
Og vi får den nye version som vi skal.
Nu har jeg iøvrigt prøvet at teste cache af static data. Og jeg kan slet ikke genskabe dit problem.
Standard Tomcat 6.0.18.
Standard FireFox 3.0.
Vi laver en test.txt.
Request:
GET /test/test.txt HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true; ...
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
...
Last-Modified: Mon, 22 Jun 2009 23:27:01 GMT
Content-Type: text/plain
Content-Length: 12
Date: Mon, 22 Jun 2009 23:27:52 GMT
Version 1.
Indhold hentes helt normalt.
Så prøver vi igen.
Request:
GET /test/test.txt HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true; ...
If-Modified-Since: Mon, 22 Jun 2009 23:27:01 GMT
...
Cache-Control: max-age=0
Response:
HTTP/1.1 304 Not Modified
Server: Apache-Coyote/1.1
...
Date: Mon, 22 Jun 2009 23:29:10 GMT
Det er jo helt som det skal være. Der er ikke ændret i filen, så browserens kopi er OK.
Vi retter i test.txt.
Request:
GET /test/test.txt HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true; ...
If-Modified-Since: Mon, 22 Jun 2009 23:27:01 GMT
...
Cache-Control: max-age=0
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
...
Last-Modified: Mon, 22 Jun 2009 23:29:58 GMT
Content-Type: text/plain
Content-Length: 12
Date: Mon, 22 Jun 2009 23:30:02 GMT
Version 2.
Og vi får den nye version som vi skal.
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund