Java a JSP - nebe a peklo (diskuse)

[Filip Jirsák]

JSP se zabýváte proto, že chcete umět zrovna technologii JSP, nebo chcete jenom „Javu + šablony pro web“? Pokud jde o druhý případ, na JSP se vykašlete a podívejte se třeba na FreeMarker. Možná jsem proti JSP zaujatý, ale mně připadá uhozený už ten základní koncept, že se kód JSP překládá až na serveru s prvním požadavkem uživatele. Takže na server klidně můžete nahrát kód, který se ani nezkompiluje, a přijde na to až první uživatel. Celá statická typová kontrola a všechny kontroly v době překladu, což je silná stránka Javy, jsou vám k ničemu.

[alblaho]

No, Java je skutečně "dobrý" jazyk ve kterém jde úspěšně stvořit ledasco, možná už i desktopovou aplikaci.

Ale JSP, to pro mě taky žádný med nikdy nebyl. Zvláště Tomcat mi přišel jako šmejd, už proto, že měl tendenci se chovat nedeterministicky. Spolehnout se na nějaké to reloadování modifikovaných částí aplikace prostě nešlo.

Možná místo Tomcatu zkusit něco jiného (Jetty?).

Ono pro vývoj webových aplikací je fakt asi nejlepší něco, co se nemusí kompilovat. Ruby, Python, to PHP je sice opravdu blivaj blivajzovitej, ale zas to má hostingovou podporu.

[Heron]

co se nemusí kompilovat

No to klidně, ale musí to mít min. kontrolu syntaxe, když už nic jako kompilaci, která obhalí i další chyby.

[alblaho]

No tak kontrolu syntaxe mají Python (ten určite), ale asi i Ruby a PHP. Nebo ne? Vždyť to přece musí rozparsovat.

[Heron]

Tak zrovna PHP se v klidu spustí a v momentě, kdy dojede na vadné místo tak spadne (500 Internal Server Error). Pokud se do té funkce leze jednou za sto let, tak to nemáš šanci zjistit. Asi budou existovat editory, které toto umí pohlídat, ale...

[SJ]

Asi jste ještě neslyšel o testech, nedejbože o TDD.

[...]

PHP nema s "500 Internal Server Error" vubec nic spolecneho vy tupy nedouku. Obsahuje standardni chybove hlasky a ma take podporu pro Exceptions, ale rikat toto nekomu, kdo si pres echo vypisuje HTML a mysli si, ze to je tak spravne, je asi zbytecne.

[Ladicek]

Výjimky? To je taková ta fíčura, kterou standardní knihovna PHP nepoužívá? Proč asi?

[Non_E]

Nevím, kolik času jste nad PHP strávil, ale v PHP žádná standardní knihovna není.

[Ladicek]

Jasně že ne, protože tohle ve skutečnosti není dokumentace standardní knihovny, nýbrž skvěle vystavěný hororový román na pokračování.

[Daniel Kvasnička ml.]

skvěle vystavěný hororový román na pokračování.

No ty si delas srandu, ale ono to tak fakt v nekterych mistech je

[Ladicek]

Dvojsmysl

[Daniel Kvasnička ml.]

Interpret PHP neni jednopruchodovy. Syntakticka analyza odhali chybu driv, nez se jakykoliv kod z daneho skriptu spusti.

[Daniel Kvasnička ml.]

Spolehnout se na nějaké to reloadování modifikovaných částí aplikace prostě nešlo.

Tomcat pouzivam na vyvoj porad a s timhle jsem nikdy problem nemel. Pokud je nakonfigurovan na reload kontextu pri zmene na classpathu, vzdycky se chytne. Ze se mu po case preplni prostor pro tridy, ktere neschramstne GC (PermGen space), to uz je jina... ale tusim, ze i na to je nejaky hack (myslim jeste jiny, nez pouzit Jetty )

[Ladicek]

Hack na to žádný není, garbage collectoru neporučíte. Reference buď existuje nebo neexistuje. Něco mohou vyřešit různé listenery (JDBC, cache introspekce, logování), ale jinak je to obecně problém nedostatečné separace různých aplikací v jednom virtuálním stroji, v tomhle ohledu bude ještě zajímavý vývoj Multitasking VM

Jinak leckdy stačí hot redeploy, pokud nedojde ke strukturálním změnám, může být restart kontextu zcela zbytečně náročný.

[Dave]

Python moc hostingovou podporu nema. Ciste proto, ze je v podstate nemozne python hosting zabezpecit tak aby nemohly byt pousteny sys metody. Na druhou stranu zavrhnout jinak dost elegantni jazyk jen kvuli jinemu odsazovani? Mi naopak diky tomu prijde kod v pythonu citelnejsi.

[Deleted [8409]]

Já třeba používám python, ale máme na to vlastní server na kterém prostě tento kód nenecháme pustit. Ale v mailing listu frameworku pylons se teď řešilo jako zprovoznit pylons na google app engine a je to údajně velmi jednoduché :)

(to se netýká jen pylons, půjde určitě i django, tg, ...)

[Daniel Kvasnička ml.]

Django by na Google App Engine melo jet, kdyz je to defaultni framework, kteremu tam Google udelil pozehnani

[kralyk z abclinuxu]

Java je neposlušné díte C++

[deda.jabko]

sice jsem s javou a jsp dlouho nedelal (radove roky)... ale pokud jste ve webove aplikaci pouzil System.out.println, tak by se vystup mel zapisovat do logu tomcatu. cely web server restartovat nemusite, staci kdyz reloadnete context, je to v administraci tomcatu.

pouzival jsem na to nejaky plugin do eclipse (zkuste se po necem podivat), ktery mj. umel zobrazovat i vystup z logu do konzole, ktera je v eclipse.

[Daniel Kvasnička ml.]

Kniha tvrdila, že pokud použiji System.out, výstup uvidím. Neříkala kde, nezdálo se mi to a dle očekávání jsem také houby viděl.

Stacilo by tu aplikaci psat treba v Eclipse. Vystup byste videl v konzoli. Od toho ty IDE jsou, abyste nemusel travit cas resenim blbosti Kazdopadne by ale melo jit Tomcat nakonfigurovat tak, aby vypisoval rovnou do konzole, ze ktere jste ho spustil. Treba Jetty to umi.

Sláva, přeci jen to asi bude logovat, ale napřed se musí log4j nakonfigurovat, což asi taky bude stát za to....

Zas tak strasne to neni http://tomcat.apache.org/tomcat-6.0-doc/logging.html

Když ve zdrojáku objektu (.java) udělám nějakou drobnou změnu a znovu jej překompiluji, Tomcat má stále někde nacacheovaný ten starý. Dle google nezbývá, než prostě kontejner restartovat. To musím vážně kvůli změně jednoho písmenka restartovat celý kontejner (tedy webserver)? Vždyť to je na hlavu padlé...

Staci redeploy daneho kontextu. Restart serveru AFAIK neni nutny. Zkuste nejake vyvojove prostredi, ktere automaticky po ulozeni *.java tridu zkompiluje a nastavte si ho tak, at ji kompiluje to WEB-INF/classes a Tomcat tak, aby reloadoval kontext. Nebo pouzijte Eclipse a nemusite tohle vubec resit.

Pokud je v kódu chyba zobrazí se v prohlížeči výpis výjimky. Pokud stránku obnovím (se SHIFTem!), rázem se objeví stránka bez chyby, ovšem nějaká předchozí (někde - ne v browseru - nacacheovaná verze), ta je tam ještě několik následujících reloadů a zhruba při pátém se zase objeví chybový výpis. A tak stále dokola...

Jo, jo, to dela. Nekde mu tam asi jeste visi ta stara classa bez chyby...

[Leoš Literák]

Neni treba redeploy, pokud se nemeni signatura metody, tak v debug modu zafunguje class reloading a java vymeni jen tu jedinou tridu, coz zabere par sekund a vy muzete pokracovat dale.

[Daniel Kvasnička ml.]

To jsem si nikdy ani nevsiml. Ale je fakt, ze ja debug mod pouzivam fakt jen kdyz potrebuju breakpointy a krokovat... asi ho zacnu pouzivat vice

[podlesh]

Jo, to je velmi užitečná věc.

Existuje i možnost měnit i bez standardních omezení, viz

http://www.zeroturnaround.com/javarebel/

[Ladicek]

Zkoušel jsi to někdy? Párkrát už jsem na to narazil, ale neodhodlal jsem se to vyzkoušet, tak by mne zajímaly zkušenosti. Teda hlavně problémy, nevěřím, že žádné nejsou.

[podlesh]

Osobně ještě ne, ale slyšel jsem velmi kladné reference.

[alblaho]

Fíha, to vypadá zajímavě. Skoro bych nevěřil, že JVM jde takovýmto způsobem tweakovat a ještě k tomu pluginem.

By mě zajímalo, jak se takový hack realizuje.

[Jiří Svoboda]

Ani nevíte, jak jsem rád za těch pár komentářů. Díky všem!

BTW, do Jetty (vím, že na něm běží abclinuxu.cz) jsem nešel jen proto, že jsem se chtěl seznámit s Tomcatem jako "standardem".

[finc]

Podle meho je na zacatek nejlepsi vyzkouset bundle netbeans+tomcat. Dane IDE integruje i tomcat konsoli, takze uvidis i vypisy, ktere tvuj program posila.

Logovani je pro mne dost zasadni vec. Pouzivam ji dost pri vyvoji, testovani i pri nasazeni. Logovani ma definovano nekolik urovni (debug, info, error, ...). Diky konfiguraci muzes dane urovne "zapinat", "vypinat" ci nechat presmerovavat do konsole, do databaze, do souboru, atd. Pri produkcnim nasazeni muze mit tu vyhodu, ze naleznes tezkoodhalitelne chyby, ktere se vyskytnou pri spatne konstalaci hvezd (napr. uzivatel provedl ukony, s kterymi jsi nepocital). Diky logovani vidis co user provedl a kde se neco spatne stalo.

Pokud je pro tebe JSP a Tomcat peklo, tak by me zajimalo, co zacnes rikat na JSF, JTA, EJB3 ci RMI. Pod kazdou zkratkou naleznes technologii, ktera je dosti rozsahla a ne vzdy snadno pochopitelna :)

[Ladicek]

Pokud je pro tebe JSP a Tomcat peklo, tak by me zajimalo, co zacnes rikat na JSF, JTA, EJB3 ci RMI.

Co by měl říkat. Začne používat technologie, které umožňují to samé bez té ohromné spousty nepoužitelného balastu (hint: Spring a Wicket).

[Leoš Literák]

Nechces se ucit javu programovanim abicka?

Jinak me zarazi, ze vystup do System.out nebyl ulozen do logu tomcatu. Obecne je vhodne si vzit treba log4j (nebo jakarta logging), nakonfigurovat jej a ukladat informace do nej. Standardni java.logging moc rad nemam. U jsp je pravidlo necpat do nej zadny kod (skriptlety), pouzivat jej jen na zobrazovani. Jinak se dostanes na uroven programovani v PHP se vsemi problemy. Java umoznuje snadnou separaci modelu, dat a logiky (MVC pattern), tak by to clovek mel pouzivat.

[hikikomori82]

To co tu popisujes mi pripada ako prechadzka ruzovym sadom. Ked chces zazit skutocne peklo, skus si niekedy naprogramovat nieco v XUL-e.