- This topic has 8 hozzászólás, 4 résztvevő, and was last updated 19 years, 1 months telt el by
.
-
Bejegyzés
-
Más.
1. Hogy lehet legegyszerûbben jsp-ben kiíratni az aktuális dátumot ebben a formátumban: 2006-05-23 ?
2. Hogy lehet kiíratni az elõbbihez hasonlóan az aktuális-hoz képest 1 héttel késõbbi dátumot?A Tomcatba telepített tartalmak módosítása után újra kell töltetni azokat (reload). Az újabb verzióknak van egy webes admin felülete, ahol csak a megfelelõ funkciólinkre kell kattintani. A régebbieknél ugyanez csak címsorba írt, paraméterezett utasításokkal ment. Ha erre szorulsz, nézd meg a beépített dokumentációban a pontos formátumot.
Ez furcsa. Ez azt jelenti, hogy ha van egy neten mûködõ Tomcat szerver, ami futtat mondjuk 30db context-et, amit 30 különbözõ jsp-fejlesztõ fejlesztget és tölti fel a fájljait ftp-vel, akkor mindenkinek hozzáférést kell adnom az admin felülethez? Azt nem lehet globálisan beállítani, hogy a szerver egyszerûen nézze meg, hogy változott -e a jsp fájl és ha igen, akkor mindenképp fordítsa újra és írja felül a régi class fájlt? Elég gáz, ha minden apró jsp-módosítást követõen (túl azon, hogy újra feltöltöm a fájlt) „tutujgatnom” kell a már nem aktuális class -fájlokat is…
Nem értem, nem erre találták ki ezt?
http://tomcat.apache.org/tomcat-5.5-doc/config/host.html#Automatic%20Application%20DeploymentPl a Host konténer attribútumai közt van egy ‘autoDeploy’. Nem erre van éppen?
Az autoDeploy a leírás szerint a Catalina indításakor húzza be automatikusan az elérhetõ alkalmazásokat. Futás közben nem nézegeti a változásokat.
Talán olvasd már el a második bekezdést is!
In addition to the automatic deployment that occurs at startup time, you can also request that new XML configuration files, WAR files, or subdirectories (containing web applications) that are dropped in to the appBase (or $CATALINA_HOME/conf/[engine_name]/[host_name] in the case of an XML configuration file) directory while Tomcat is running will be automatically deployed, according to the rules described above. The auto deployer will also track web applications for the following changes:
* An update to the WEB-INF/web.xml file will trigger a reload of the web application
* An update to a WAR which has been expanded will trigger an undeploy (with a removal of the expanded webapp), followed by a deployment
* An update to a XML configuration file will trigger an undeploy (without the removal of any expanded directory), followed by a deployment of the associated web applicationIgaz, ez külön, egyes jsp fájok módosítását nem veszi észre, de talán megoldás a problémára.
Köszi. Mindenestre a fõ cél az pont az egyes jsp féjlok módosításának észlelése, hogy ha beírok egy plussz out.println(„Kakukk”) sort a valami.jsp fájlba, ne kelljen a valami.class-t törölgetni.
Hátha nem haszontalan egy ilyen topik. Php után elég sokat szívok vele.
1. Mindjárt egy kérdés, ami inkább a Tomcat-hez kapcsolódik (kicsit off). A Tomcat alapból a 8080-as portot figyeli. Mellette van egy Apache a 80-as porton. Egymás mellett mennek. Tegyük fel, hogy van 20 db domain, ami name virtualhost-ként az Apache „felügyelete alatt áll” (statikus html, illetve php oldalak) és van 2 db olyan domain, ami jsp-technológiájú honlappal rendelkezik. Nyilván nem várhatom el a két utóbbi honlap látogatóitól, hogy a „8080”-as portot is beírják a domain után a böngészõbe. Hogy érhetem el, hogy a két utóbbi domain esetében a foldolgozást port beírás nélkül (http://www.valami.hu) a tomcat kapja. Létre kell hozni az apache-ban is virtuálhosztot nekik, ami nem csinál mást mint átirányít a 8080-ra, vagy mi a megoldás?
2. Amikor feltöltök a Tomcat context-be egy valami.jsp-t, futtatáskor befordítja class-ba (a ./../work dir-ben, majd a böngészõ megjeleníti. Minden szép. Ha azonban korrigálok a jsp-n és újra feltöltöm a browser továbbra is az elõzõ class-t futtatja. Miért? Gondolom létezik megoldás azon kívül, hogy minden vesszõkorrekció után manuálisan töröljem a work- könyvtár class-ait. Erre lennék kiváncsi:)
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz