Kipróbáltam a Grails-t, és nagyon tetszik. A végeredmény JVM-ben fut, így felkerült egy Tomcat egy virtuális szerverre.
Ha kiadom a grails war parancsot, akkor csinál nekem egy war fájlt, ami - ha jól értem - egy zip állomány, amiben minden benne van ami kell, és ezt egyben föl lehet tölteni a Tomcat manager alkalmazásával.
A projekt, amire használtam nem túl nagy, de úgy döntöttem, hogy épp megfelelő a rendszer első kipróbálásához. Azóta egy kicsit kényelmetlenül érzem magamat, mert ha azt kérik, hogy cseréljek le valami apróságot, akkor mindig war-okat undeployolok és deployolok, amik darabonként ~24 MB-osak, és fél órán át töltöm őket föl... :)
Elvileg a nézetek újratöltésére találtam megoldást (bár még nem ellenőriztem), de meg lehetne ezt csinálni a rendszer egészével (.class fájlokkal) is?
Tehát a kérdésem: muszáj nekem mindig war-t töltögetnem, vagy ftp-n is meg tudom ezt oldani kisebb egységekben? Ha igen, akkor hogyan? Csináljak war-t, bontsam ki, és a megfelelő részeit töltsem föl, aztán indítsam újra az alkalmazást? Hogy szokás ezt csinálni?
- 1693 megtekintés
Hozzászólások
Ne warként tedd fel a Tomcat alá, hanem kicsomagolt állapotban.
Tehát webapps/mywebapp.war helyett webapps/mywebapp könyvtár és benne minden ami a warban volt. Akkor szinkronizálhatod ftp-n csak a módosult fájlokat. Ha classok módosulnak, akkor újra kell tölteni az alkalmazást. Manager-ben reload vagy ha a Tomcat alapbeállítások mellett fut, akkor a web.xml módosítási dátumát kell frissíteni (pl.: touch) és automatikusan újratölti az alkalmazást.
- A hozzászóláshoz be kell jelentkezni
Értem.
Van a grails-ben olyan, hogy a template fájlokat lefordítja, és .class állományokkal dolgozik helyettük. Amit írtam, hogy a nézetek újratöltésével kapcsolatban találtam, az végül nem működött, viszont van egy állomány, ami leírja, hogy melyik .gsp-hez melyik .class tartozik. (Pl.: /WEB-INF/grails-app/views/index/index.gsp=gsp_xyz_indexindex_gsp, tehát ezek a precompiled dolgok) Ha ezeket az összerendeléseket kitörlöm, akkor minden reload után érvényesülnek a .gsp-kben történt változások.
De mi történik reload-nál, vagy az első oldalbetöltésnél? (A gsp betöltése és feldolgozása miért csak egyszer történik meg? A memóriába kerül minden dolog rögtön indításkor?)
- A hozzászóláshoz be kell jelentkezni
Jól értem a gsp-ket még a grails fordítja le neked class-okra, amikor a war-t előállítod (precompile emlegetéséből gondolom)? A class-okat hova teszi (a WEB-INF/classes-ba esetleg egy jar-ba a WEB-INF/lib alá)?
"Ha ezeket az összerendeléseket kitörlöm, akkor minden reload után érvényesülnek a .gsp-kben történt változások."
Mármint oldal és nem webapp újratöltésre gondolsz itt ugye? Legalábbis az előbbi az érdekes, az utóbbira a jelenség természetes. :)
"De mi történik reload-nál, vagy az első oldalbetöltésnél? (A gsp betöltése és feldolgozása miért csak egyszer történik meg? A memóriába kerül minden dolog rögtön indításkor?)"
A java webappok folyamatosan futó processzek, részben ezért is hívják őket alkalmazásnak és nem szkriptnek. A class-okat egy classloader tölti be és azok folyamatosan a memóriában vannak, amíg a webapp fut (ez alól kivételek a jsp-kből forgatott class-ok, de ez most részletkérdés). A classloader a webapphoz tartozik. Ha a webappot leállítod, akkor eldobja a classloadert is és minden class-t amit az betöltött. Az újrainduló alkalmazás újra betölti a class-okat (a potenciálisan megváltozott) fájlból.
Én még nem dolgoztam grails-szel, de amit elmondtál az alapján úgy tűnik, hogy tud precompile módban (amikor class-ra forgatott változattal dolgozik) és runtime értelmezéssel (amikor kitörölted az összerendelést és így nincsenek meg számára a class-ok csak a gsp-k) is kiszolgálni gsp-ket. Ennek esetleg a kiszolgálási sebességre lehet hatása. El tudom képzelni, hogy a 2. mód lassabb, de nem hiszem, hogy jelentősen. Mindenesetre ezt nézd meg, mert úgy látom van olyan opció, hogy precompile is legyen, de a módosításokat is észrevegye on the fly (ott leírják, hogy "grails.gsp.enable.reload" az opció helyes neve és nem "grails.gsp.reload.enable", ahogy a dokumentációban van/volt).
- A hozzászóláshoz be kell jelentkezni
Tényleg keverve írtam le :)
Pusztán gsp-vel az alkalmazást indítottam újra, tehát ilyenkor frissült a dolog (= természetes jelenség). A célom pedig a runtime értelmezés.
A gsp-ket a grails fordítja le, a WEB-INF/classes-be kerülnek. A WEB-INF/lib-ben a nagyágyúk vannak (spring, hibernate, stb, összesen 62 jar fájl), és ezek teszik ki a ~24 MB 99%-át. Ezeket ki lehet hagyni a war-ból a --nojars kapcsolóval.
Az oldalbetöltődést úgy kevertem ide, hogy rémlik nekem valami, amit egy nálam okosabb ember mondott nekem, és valami olyan volt, hogy a JVM vagy a Tomcat a weboldal első elérésekor csinál valamit valamivel, egyszeri alkalommal.
Kipróbáltam a grails.gsp.enable.reload-ot, tényleg működik. Én is megtaláltam, de nem tűnt logikusnak a másikhoz képest, úgyhogy szkeptikus voltam. Aztán találtam bizonyítékot. Nem értem, hogy miért van a többihez képes fordítva.
A war kibontása utáni feltöltés és újraindítás is működik, runtime értelmezés is van, úgyhogy minden megoldódott.
Köszönöm a segítséget és a magyarázatot is!
- A hozzászóláshoz be kell jelentkezni
Az újratöltéssel vigyázni kell, bizonyos keretrendszerek használatakor nem sikerül a classloader-nek mindent kitakarítani a memóriából, így Java.lang.OutOfMemoryError: PermGen space hibát kaphatsz, esetleg pár újratöltés/deploy után. Ha ilyent tapasztalsz, a Tomcat újraindítás is ajánlott.
- A hozzászóláshoz be kell jelentkezni
Az új Tomcat verziókban (6.0.valamitől felfele, de a 7-esekben végig) van memory leak detector ami ezeket a hibákat észreveszi (logol warningot) és javítja (!) is. Ilyet egyik másik servlet container sem tud még egyelőre.
- A hozzászóláshoz be kell jelentkezni
bookmark
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)
- A hozzászóláshoz be kell jelentkezni