Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Zelenac 13. 02. 2016, 22:59:06
-
Chápu to dobře, že aplikační server dle Java EE představuje celý middletier?
Tj. řekněme že mám DB, middle tier a tenkého klienta. Potom na middletieru by mělo být implementováno JPA pro komunikaci s DB, jestli rozumím tak potom třídy, ve kterých budu tuto logiku psát, představují jednotlivé EJB, a potom komunikaci s clientem, zde by mělo být použito JMS. No a nepovedlo se mi přesně zjistit, co si představit pod aplikačním serverem, ale nějak mi z toho plyne, že by mohl být schopen tvořit celý middletier ve smyslu tom, že žádnou svou aplikaci nepíšu, ale prostě si jen nakonfiguruju aplikační server a z tenkého klienta veškeré tahání dat z DB probíhá přes něj.
Pokud to tak není, tak by mě zajímalo, proč třeba Glassfish umožňuje správovat připojení k databázím, když tato funkcionalita kupříkladu v NetBeans píše se za použití JPA implementaci v eclipselink (eventuálně Hibernate JPA), takže správa připojení k DB je zahrnuta přímo ve vytvářených třídách. (potom existuje 2x jedna a ta samá věc . jakási správa DB v aplikačním servru + JPA impementované ve třídách).
-
Aplikační server (a nejen podle Java EE) je pro enterprase aplikace obrazně řečeno zhruba totéž, co operační systém pro "normální" aplikace. Čili poskytuje běhové prostředí pro třeba EJB či všelijaké jiné entity, komponenty atd. (které se opět obecně, nejen Java EE, mohou nazývat různě), ty samy o sobě totiž spustit nepůjdou.
Dále může poskytovat různé další služby, např. management VM a monitoring. Typicky poskytuje prostředky a rozhraní pro deployment, tzn. instalaci, spouštění a zastavování aplikací. Může spravovat uživatelská oprávnění, přičemž aplikace se o to pak nemusí starat. Totéž platí o správě DB připojení - aplikace jen používá existující data source a nestará se o jeho konfiguraci (naopak konkrétní DB dotazy, které mohou být implementovány jak přímo, tak prostřednictvím JPA, Hibernate atd. jsou záležitostí aplikace a nikoliv aplikačního serveru). Může sloužit jako servletový kontejner - opět, aplikace řeší jen konkrétní implementaci nějakého servletu, neřeší ale, jak jej spustit, jak jej zpřístupnit přes HTTP(S) atd. Některé aplikační servery mohou poskytovat i portálové rozhraní, což je ještě vyšší abstrakce než servlety, dále třeba podporu pro integraci procesů atd. atd. Na co jsem ještě zapomněl?
Stručně řečeno, aplikační server umožňuje aplikaci samotné soustředit se na business logiku, přičemž on sám jí zajistí to, co by se jinak muselo psát tisíckrát znova pro každou samostatnou aplikaci (a tisíckrát špatně, anebo přinejlepším by se jen znovu vynalézalo kolo).
-
Aplikační server (a nejen podle Java EE) je pro enterprase aplikace obrazně řečeno zhruba totéž, co operační systém pro "normální" aplikace. Čili poskytuje běhové prostředí pro třeba EJB či všelijaké jiné entity, komponenty atd. (které se opět obecně, nejen Java EE, mohou nazývat různě), ty samy o sobě totiž spustit nepůjdou.
Dále může poskytovat různé další služby, např. management VM a monitoring. Typicky poskytuje prostředky a rozhraní pro deployment, tzn. instalaci, spouštění a zastavování aplikací. Může spravovat uživatelská oprávnění, přičemž aplikace se o to pak nemusí starat. Totéž platí o správě DB připojení - aplikace jen používá existující data source a nestará se o jeho konfiguraci (naopak konkrétní DB dotazy, které mohou být implementovány jak přímo, tak prostřednictvím JPA, Hibernate atd. jsou záležitostí aplikace a nikoliv aplikačního serveru). Může sloužit jako servletový kontejner - opět, aplikace řeší jen konkrétní implementaci nějakého servletu, neřeší ale, jak jej spustit, jak jej zpřístupnit přes HTTP(S) atd. Některé aplikační servery mohou poskytovat i portálové rozhraní, což je ještě vyšší abstrakce než servlety, dále třeba podporu pro integraci procesů atd. atd. Na co jsem ještě zapomněl?
Stručně řečeno, aplikační server umožňuje aplikaci samotné soustředit se na business logiku, přičemž on sám jí zajistí to, co by se jinak muselo psát tisíckrát znova pro každou samostatnou aplikaci (a tisíckrát špatně, anebo přinejlepším by se jen znovu vynalézalo kolo).
Díky. Takže třeba Tomcat vs Glassfish. Chápu že Tomcat a další obsahují web kontejner dle Java EE, takže můžou na nich být spuštěny JSP soubory, Beany atd., ale nechápu výhodu toho DB zdroje. Proč bych se měl chtít připojovat do databáze, třeba PostgreSQL, v nějaké beaně přes aplikační server, a nikoliv přímo, přes JPA?
Dále ještě, v případě Tomcatu: vznikne HTTP request a je obsloužen příslušným Servletem, třeba index.jsp (převádí se na Servlet tak to zobecním). index.jsp používá nějakou beanu, přes kterou se načtou data z DB. Vygeneruje se request a pošle se to klientovi. Nicméně předpokládám, že po tomto kroku veškeré vytvořené instance tříd zanikají. Přitom však, pracuji-li třeba s DB, nechci se připojovat pokaždé, ale chci ať nad tím něco běží, přinejmenším by měl existovat nějaký connection pool, navíc v paměti by se měly udržovat také nějaké objekty zrcadlící DB, aby se třeba nemusely pořád načítat při každém requestu. Jak je tedy potom toto řešeno?
-
Chápu jak je to v ASP.NET, tam je DB, samostatně běžící Middletier s Entity Frameworkem přes WCF se komunikuje s klientskou částí.
Kdybych si tu samou logiku chtěl udělat v Javě, tak bych potřeboval middle tier jako jakoby samostatný *.jar, ve kterým by běželo nějaký ten ORM, nejspíš teda typu JPA. No a s tímto middletierem, který nonstop běží, by se přes tuším JMS (aby to bylo dle Java EE), komunikovalo s klientem, třeba s nějakou tou instancí beany která se zrovna vytvořila při requestu a požaduje nějaká data.
A tuším zde nějaký fígl s tím aplikačním serverem, že on umí nad sebou ten middletier rozjet.
-
Aplikační server aplikaci typicky zpřístupňuje DataSource, což je objekt, který poskytuje databázovou konekci.
A teď jednak - DataSource může být poolovaný, což je záležitost konfigurace aplikačního serveru (pro aplikaci je to transparentní, ta o žádném poolu nemusí ani vědět). A dále, jak jsem již napsal, aplikace nemusí řešit konfiguraci nějaké konkrétní DB instance... nakonfiguruje se pouze, jaký DataSource se má použít (třeba přes JNDI), v aplikačním serveru pak mohu tento DataSource přepnout na konkrétní DB instanci, což může být produkční nebo testovací DB. Mohu třeba přepínat mezi různými testovacími DB (každá s různým charakterem dat, např. pro zátěžové testy). Nebo v případě složitějších migrací přepnu z jedné produkční DB do nové, nějakým způsobem transformované atd. Případů užití by se našlo spousta. A opět to nejdůležitější - je to z pohledu aplikace transparentní.
Další důležitým aspektem je to, že v aplikačním serveru může běžet více aplikací najednou (a všechny nad jednou instancí DB). Pak není vůbec žádoucí, aby si každá z nich sama spravovala DB připojení, velikost connection poolu a jiné parametry, protože by například součet velikostí jednotlivých connection poolů mohl přesáhnout fyzické limity DB stroje, čímž by docházelo k jeho přetížení, nebo dokonce úplnému kolapsu celého ekosystému. Což mi připomíná, že aplikační server kromě connection poolu může spravovat i thread pool. Z podobných důvodů.
-
Dulezita vlastnost (i kdyz se to nemusi zdat) je, ze JEE aplikacni server musi mit vlastni (hierarchicky) class loader. To mu umozni mit v pameti vice trid se stejnym jmenem. Diky tomu mohou byt aplikace unitr serveru skutecne nezavisle. Napriklad do Tomcatu nemuzete nahrat dve ruzne verze Log4j anebo JDBC driveru. To vede k ruznym nechutnym class-loader issues.
Zatimco u JBOSS, GlassFish nemuze jedna nactena aplikace ovlivnit druhou (kazda ma vlastni jmenny prostor).
-
tále ještě, v případě Tomcatu: vznikne HTTP request a je obsloužen příslušným Servletem, třeba index.jsp (převádí se na Servlet tak to zobecním). index.jsp používá nějakou beanu, přes kterou se načtou data z DB. Vygeneruje se request a pošle se to klientovi. Nicméně předpokládám, že po tomto kroku veškeré vytvořené instance tříd zanikají.
to neni pravda. to neni php.
aplikacny server spravuje aplikace ktore sa spusta (tak ako sa spusti word vo windoze)
aplikacia bezi. aplikacia obsluhuje requesty
preto moze vzniknut bean/singlteon ktory handluje requesty, pripojenia k databaze. drzi stavove informacie v instancnych premennych.
Kdybych si tu samou logiku chtěl udělat v Javě, tak bych potřeboval middle tier jako jakoby samostatný *.jar, ve kterým by běželo nějaký ten ORM, nejspíš teda typu JPA.
java ee compliant server ma v sebe zabudovanu implementaciu jpa. vy dodate len samotnu logiku. anotacie do tried.
tomcat nie je java ee compliant server. tomcat je len servlet container. ak chcete jpa v tomcate do war dodate implementaciu jpa.
-
K tomu co pisal perceptron:
Mas teda 1 instanciu servletu na celu aplikaciu, ale ten servlet musi byt reentrantny a kazdy request je obsluhovany vo vlastnom threade, kde sa zavola nejaky ten doGet. Ale netreba to vidiet tak, ze ked mas 10 threadov, tak mozes mat max 10 keepalive spojeni. Lepsie servery maju fronty (prakticky vsetky na ktore narazis) a bez problemov obsluzia tisice spojeni. Thready byvaju poolovane, co ma vyhody aj nevyhody a treba na to mysliet.
-
Dobře tak už je mi to jasnější. Když si zkusím ve svičném projektu s Glassfishem v Netbens vytvořit Session Bean, tak potom:
- Stateless session bean je automaticky vytvořena při startu serveru. (v konstruktoru si nehcám vypsat hlášku do konzole)
- Singleton session bean je rovněž automatickyvytvořen při startu serveru.
- Stateful beana se mi nechce atomaticky vytvořit.
Proč se mi tedy nevytvoří automaticky instance Session beany při novém session?
-
Ok, tak uz jsem na to přišel, musím se na něj odvolat přes @EJB, nicméně stejně se to nechová moc logicky, protože když v servletu použíju
@EJB
StatefulBean b
Tak se použije vždy ta samá instance nehledě na to, z kterého zařízení se na servlet připojím. Jedno zařízení (jeden prohlížeč, eventálně ještě bych chápal jiná IP) by snad měla být brána jako jiná session. Když udělám jiný srvlet, vytvoří se pro něj jiná instance te beany. Singleton se chová ok.
-
nemozete injectnut bean s kratsou zivotnostou do beanu s dlhsou zivotnostou. stateful ma zivotnost sessnu. servlet zivotnost behu aplikacie
pouzite jndi lookup
-
Proč se mi tedy nevytvoří automaticky instance Session beany při novém session?
Protože slovo "Session" u "session bean" neznamená "http session" (je to klasický problém "akt" vs "pietní akt").
Když už sem píšu: několikrát jsi zmínil JMS v naprosto absurdních souvislostech... raději se tomu vyhni.
Bohužel hlavní problém J2EE je že nikde není vysvětleno o co vlastně jde a hlavně proč. To byl hlavní problém ve verzích 1 a 2 (ze kterých IBM vyloženě trčelo), ale i dnes platí že J2EE řeší problémy o kterých ani netušíš že bys mít někdy mohl (a 90% z nich nikdy mít nebudeš).
-
Dle mojí definice a menších zkušeností je Java EE server prostě normální Javovská aplikace, která přijímá HTTP požadavky (kromě jiného samozřejmě, je to dost komplexní celá ta specifikace) a vyřizuje je tím, že najde správny servlet. Ono to vypadá jako složitě ale představ si, že budeš muset napsat něco podobného jako Java EE server, tak budeš postupovat tímhle způsobem a postupně nabalovat další a další funkcionalitu. V Javě je nějaký způsob, jak se nahrávají jednotlivé třídy přes Classloadery a to umožňuje, aby Javovská aplikace zachytila snahu o použití nějaké třídy a nahrála ji. Takže ty když programuješ, tak programuješ proti nějakým interfacům třeba JPA specifikace a pak ten server ti "dodá" nějakou implementaci.
Takže prostě normální Javovská aplikace, která poskytuje určité prostředí (třídy) skrz to nahrávání tříd.
-
Ono to vypadá jako složitě ale představ si, že budeš muset napsat něco podobného jako Java EE server
Nevíte co to je oliheň? Nic složitého, představte si třeba oliheň a to je vlastně ono.
-
Ok takže me problémy zdá se trochu spravily s použitím JSF. Tady mi sice funguje práce s ManagedBean, ve které použiju přes @EJB Stateful-Beanu, nicméně teď vznikl zase druhý extreém, že při aktualizaci stránky s jednouchým counterem (přes AJAX tag) se mi vždy vynuluje counter, tudíž vytvoří se mi nová instance Stateful-Beany. Singleton beana funguje srpávně. Rovněž výtáhnu-li si v ManagedBeaně request.getSession() do kterého si vložím setAttribute("counter", Integer), tak tento request session se chová stejně jako Session Bean (@stateful), totiž že zaniká při aktualizaci stránky.
Zde navíc vzniká pro měn nepochopitelná situace, že když udělám:
public void increment() {
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
Integer i = (Integer)request.getSession().getAttribute("counter");
i += 1;
}
Tak se mi "i += 1" nepromítně do hodnoty uložené v session, musím proto přidat:
request.getSession().setAttribute("counter", i);
Abych vložil hodnoty zpět. Tudíž pro mě nepochopitelně se mi nepředává instance typu Integer odkazem, ale hodnotou. :o
-
Tudíž pro mě nepochopitelně se mi nepředává instance typu Integer odkazem, ale hodnotou. :o
Nic takoveho totiz v jave neni. Ze je to pro tebe nepochopitelne ukazuje, ze nejsi ani na urovni uvodniho tutorialu Java SE. Aby ses zabyval EE je tedy znacne predcasne, nebudes pravdepodobne zadnemu kodu rozumet.
-
public void increment() {
HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance().getExternalContext().getRequest();
Integer i = (Integer)request.getSession().getAttribute("counter");
i += 1;
}
Tak se mi "i += 1" nepromítně do hodnoty uložené v session, musím proto přidat:
request.getSession().setAttribute("counter", i);
Abych vložil hodnoty zpět. Tudíž pro mě nepochopitelně se mi nepředává instance typu Integer odkazem, ale hodnotou. :o
Co nedelat takovehle veci jeste pred tim, co se doucis zaklady?
http://lmgtfy.com/?q=java.lang.integer+mutability
-
Tudíž pro mě nepochopitelně se mi nepředává instance typu Integer odkazem, ale hodnotou. :o
Nic takoveho totiz v jave neni. Ze je to pro tebe nepochopitelne ukazuje, ze nejsi ani na urovni uvodniho tutorialu Java SE. Aby ses zabyval EE je tedy znacne predcasne, nebudes pravdepodobne zadnemu kodu rozumet.
Tak to zase ne. On dostava odkaz na instanci tridy Integer. Jenomze tyhle instance jsou immutable uplne stejne jako string.
-
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
-
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
Nauc se (poradne!) Javu. Pak se uc JEE. Zrovna tohle je jednoduche a neni na tom o cem premyslet.
-
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
Nauc se (poradne!) Javu. Pak se uc JEE. Zrovna tohle je jednoduche a neni na tom o cem premyslet.
No vždyť to je jednoduché, jen jsem o to ještě nezavadil, díkes za odkaz a tě péro. Nebo sis snad myslel, že neznám imutable dat typy protože je to složité? A z toho sis odvodil, že bych se proto neměl učit Javu EE? Děláš si zadek?
Takže problém se session už jsem vyřešil, getSessionId(true) vytvoří sessionid relativně k prohlížeči a vrátí jeho hodnotu. Hurá.
-
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
Nauc se (poradne!) Javu. Pak se uc JEE. Zrovna tohle je jednoduche a neni na tom o cem premyslet.
A ted kdyz se ucim Javu EE, to si mám asi dle tvé logiky taky nejdříve přečíst bichli jménem Java EE a potom začít teprve něco zkoušet?
-
Tak to zase ne. On dostava odkaz na instanci tridy Integer. Jenomze tyhle instance jsou immutable uplne stejne jako string.
Jiste, a mohl by to misto toho dostat hodnotou? Proste ten koncept pointer/nepointer a ruzneho chovani v techto pripadech pro instance trid v jave vubec neexistuje. Nema tedy smysl si jim vysvetlovat, ze se nekde neco neinkrementovalo.
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
Jsi sice troll, ale odpovim ti. Jsi ve stavu, kdy si muzes precist treba neco o EE architekture. Nejsi ve stavu, ze si muzes zkouset konkretni priklady, kdyz v jave NEUMIS VUBEC PROGRAMOVAT. Nebo ti pripada normalni, ze nevis, jak se pricte jednicka? Co od takoveho "pruzkumu" ocekavas (recnicka otazka)?
-
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
Nauc se (poradne!) Javu. Pak se uc JEE. Zrovna tohle je jednoduche a neni na tom o cem premyslet.
No vždyť to je jednoduché, jen jsem o to ještě nezavadil, díkes za odkaz a tě péro. Nebo sis snad myslel, že neznám imutable dat typy protože je to složité? A z toho sis odvodil, že bych se proto neměl učit Javu EE? Děláš si zadek?
Takže problém se session už jsem vyřešil, getSessionId(true) vytvoří sessionid relativně k prohlížeči a vrátí jeho hodnotu. Hurá.
Jednoduche je prijit na to, ze clovek ma zacit zakladama. A kdyz to neudela a nabehne si, tak by od nej alespon bylo hezke, aby videl chybu v sobe ;)
-
Tak to zase ne. On dostava odkaz na instanci tridy Integer. Jenomze tyhle instance jsou immutable uplne stejne jako string.
Jiste, a mohl by to misto toho dostat hodnotou? Proste ten koncept pointer/nepointer a ruzneho chovani v techto pripadech pro instance trid v jave vubec neexistuje. Nema tedy smysl si jim vysvetlovat, ze se nekde neco neinkrementovalo.
Ono je to jeste o chlup slozitejsi. Tady by to chovani bylo navenek stejne (mimo situace, kdy dostanes z volani getAttribute() null, pak ti to, co vypada jenom jako aritmetika, vyhodi NPE, protoze se tam auto(un)boxuje) pro int i Integer, ale spravne vysvetleni pro stejne chovani uz se lisi. A neni zas takovy problem zkonstruovat priklad, kde ten rozdil poznas.
-
Ono je to jeste o chlup slozitejsi. Tady by to chovani bylo navenek stejne (mimo situace, kdy dostanes z volani getAttribute() null, pak ti to, co vypada jenom jako aritmetika, vyhodi NPE, protoze se tam auto(un)boxuje) pro int i Integer, ale spravne vysvetleni pro stejne chovani uz se lisi. A neni zas takovy problem zkonstruovat priklad, kde ten rozdil poznas.
V cem je to slozitejsi? Instance Integer nemuze byt nikam predana "hodnotou", to je to co tvrdim - je to snad jinak? Tedy rozhodne zde neni duvodem, proc se nezmenila hodnota na session, nejake predavani hodnotou.
-
Tak to zase ne. On dostava odkaz na instanci tridy Integer. Jenomze tyhle instance jsou immutable uplne stejne jako string.
Jiste, a mohl by to misto toho dostat hodnotou? Proste ten koncept pointer/nepointer a ruzneho chovani v techto pripadech pro instance trid v jave vubec neexistuje. Nema tedy smysl si jim vysvetlovat, ze se nekde neco neinkrementovalo.
To jsem si dovolil opravdu hodně, že se učím Javu EE když neznám imutable typy.
Jsi sice troll, ale odpovim ti. Jsi ve stavu, kdy si muzes precist treba neco o EE architekture. Nejsi ve stavu, ze si muzes zkouset konkretni priklady, kdyz v jave NEUMIS VUBEC PROGRAMOVAT. Nebo ti pripada normalni, ze nevis, jak se pricte jednicka? Co od takoveho "pruzkumu" ocekavas (recnicka otazka)?
A co když jsem tam předtím přičítal 666 a pak to změnil na jedničku? Co když jsem si nebyl jistý, jestli na podivně se chovající typ Integer vůbec funguje ++? Prestaň mi tu zasírat téma, já si tu klidně budu povídat pro sebe, když nikdo nebude mít zájem reagovat na moje dotazy. Nepotřebuju tady poslouchat kydy od někoho, kdo se mi snaží tvrdit, že si nemůžu udělat ani counter a vyzjistit, jak se v JEE pracuje se session.
Tak a teď se to rozjede flame a já si pak založím další téma. (na tento příspěvek dám odkaz, až mi nějaký blbec bude pro změnu říkat, proč jsem zase založil nové téma)
-
Co když jsem si nebyl jistý, jestli na podivně se chovající typ Integer vůbec funguje ++?
Coz by sis mel byt jisty, kdyz delas takovehle veci. Ver mi: budes si porad dokola nabihat na vidle se zaklady.
-
Co když jsem si nebyl jistý, jestli na podivně se chovající typ Integer vůbec funguje ++?
Coz by sis mel byt jisty, kdyz delas takovehle veci. Ver mi: budes si porad dokola nabihat na vidle se zaklady.
Teď mám o jeden základ vystaráno - imutable datové typy. Víš jak jsem se o něm dozvědel? Tak, že jsem si dělal counter v Java EE. Učím se tedy očividně s Javou EE i základy Javy? Ano, učím. Děkuji za pochopení, nashledanou.
-
Co když jsem si nebyl jistý, jestli na podivně se chovající typ Integer vůbec funguje ++?
Coz by sis mel byt jisty, kdyz delas takovehle veci. Ver mi: budes si porad dokola nabihat na vidle se zaklady.
Teď mám o jeden základ vystaráno - imutable datové typy. Víš jak jsem se o něm dozvědel? Tak, že jsem si dělal counter v Java EE. Učím se tedy očividně s Javou EE i základy Javy? Ano, učím. Děkuji za pochopení, nashledanou.
Tak jeste 512 veci, ktere se naucis tak, ze si o ne rozbijes usta.... (a budes s tim otravovat ostatni a budes to povazovat za chybu Javy a ne svou neznalost)
Ale fakt je, ze nekolik mesicu zoufalych pokusu muze casto nahradit i cely vikend poctiveho studia ;)
-
Učím se tedy očividně s Javou EE i základy Javy? Ano, učím.
to je pekne drzim palce
problem je v tom ze riesite vela veci naraz a chaoticky. riesite jsf a pritom zacnete riesit http sessny (dost zbytocne) a pri rieseni http sessnov zistite ze to funguje rovnako ako v .net a zacnete riesit immutabilitu. vsetko to navyse diskutujete cez root co je mimoriadne pomale medium
a to ste za dva dni urobili counter.
teda fakt drzim palce ale toto nie je idealny sposob ucenia sa. rezignujete s tym ze budete chodit po krcmach a nadavat na javu.
-
Učím se tedy očividně s Javou EE i základy Javy? Ano, učím.
to je pekne drzim palce
problem je v tom ze riesite vela veci naraz a chaoticky. riesite jsf a pritom zacnete riesit http sessny (dost zbytocne) a pri rieseni http sessnov zistite ze to funguje rovnako ako v .net a zacnete riesit immutabilitu. vsetko to navyse diskutujete cez root co je mimoriadne pomale medium
a to ste za dva dni urobili counter.
teda fakt drzim palce ale toto nie je idealny sposob ucenia sa. rezignujete s tym ze budete chodit po krcmach a nadavat na javu.
Perceptron, ty máš v te hlavě zřejmě jenom jeden.
-
Klidek..my javisti sme zhovievavi a mame nekonecnu trpezlivost. Preto odporucana literatura:
Head First Java, 2nd Edition By Kathy Sierra, Bert Bates
Head First Servlets and JSP, 2nd Edition
Najdes tam odpovede na mnoho svojich otazok a myslim, ze ucit sa takto cez forum ma pre teba zmysel snad iba ak si nasiel recept na dlhovekost.
-
Klidek..my javisti sme zhovievavi a mame nekonecnu trpezlivost. Preto odporucana literatura:
Head First Java, 2nd Edition By Kathy Sierra, Bert Bates
Head First Servlets and JSP, 2nd Edition
Najdes tam odpovede na mnoho svojich otazok a myslim, ze ucit sa takto cez forum ma pre teba zmysel snad iba ak si nasiel recept na dlhovekost.
No to druhé moc ne, přece se nebudu dneska učit JSF? Od roku 2009 je JSP deprecated 8)
-
Neumis Java, neumis JSF, neumis Jave EE, nevis nic o Servletech,... ale po nas chces abychom ti vysvetlili, proc ta debilni Java nefunguje.
To je pak tezky a vysledek bude podle toho vypadat...
-
Klidek..my javisti sme zhovievavi a mame nekonecnu trpezlivost. Preto odporucana literatura:
Head First Java, 2nd Edition By Kathy Sierra, Bert Bates
Head First Servlets and JSP, 2nd Edition
Najdes tam odpovede na mnoho svojich otazok a myslim, ze ucit sa takto cez forum ma pre teba zmysel snad iba ak si nasiel recept na dlhovekost.
No to druhé moc ne, přece se nebudu dneska učit JSF? Od roku 2009 je JSP deprecated 8)
JSP a JSF jsou dvě různé věci a pořád se používají v produkčním kódu, takže se ta znalost neztratí. Ostatně ta knížka je hlavně o servletech, dozvíš se tam právě to důležité: životní cyklus servletů, jak se řeší session, jak se servlet používá při více požadavcích atd.
-
A co Spring, Hibernate (ne JPA verze), Struts... neni to zbytecne se to ucit, resp. v tom neco vyvijet, vzhledem k tomu zpjak jednoduche to je v J EE 7? Jako prijde mi to s JSF tak primocare a univerzalni, ze nevím moc smysl proč se učit jiné technologie.
-
Klidek..my javisti sme zhovievavi a mame nekonecnu trpezlivost. Preto odporucana literatura:
Head First Java, 2nd Edition By Kathy Sierra, Bert Bates
Head First Servlets and JSP, 2nd Edition
Najdes tam odpovede na mnoho svojich otazok a myslim, ze ucit sa takto cez forum ma pre teba zmysel snad iba ak si nasiel recept na dlhovekost.
No to druhé moc ne, přece se nebudu dneska učit JSF? Od roku 2009 je JSP deprecated 8)
JSP a JSF jsou dvě různé věci a pořád se používají v produkčním kódu, takže se ta znalost neztratí. Ostatně ta knížka je hlavně o servletech, dozvíš se tam právě to důležité: životní cyklus servletů, jak se řeší session, jak se servlet používá při více požadavcích atd.
Tak JSF stejně jako JSP se předpokládám převádí do servletu, kde navíc u JSF se obsluhují přes nějaký ten servlet požadavky z ajaxu, tedy to co bych musel implementovat v případě jsp ručně. Asi na jsp někde narazím, ačkoliv si to moc nepřeji.
Jdu na obhlídku do springu a struts a jsem zvědav, co to jakože má nabídnout lepšiho, než má jsf a jeho componenty, popřípadě mix jsf a angularjs. Abych věděl, proč že se to mám učit další věc, doufám že ne uplně zbytečně, tedy včetně situce dodělávat něco do projektu po Frantovi, který použil spring z důvodu, že spring.
-
jsf je nieco totalne ine ako jsp. (ani ten prevod do servletu tam neexistuje)
struts su mrtve
spring a java ee riesia podobne problemy. kazdy po svojom.
spring v jadre nema nic ako jsf. ale spring vie pracovat s jsf.
ucit sa spring alebo java ee kvoli samemu uceniu je zbytocne ked mate attention span 3 dni a taketo rozsiahle veci