Názory k článku JBoss: Intermezzo - ukázka využití
-
Pavel TišnovskýZlatý podporovatelSplnuje opravdu ta prvni trida podminku pro to, aby se jednalo o JavaBean?
-neni serializovatelna (to nemusi byt splneno, ale je to vhodne)
-nema public default konstruktor (to je tusim podminka nutna) -
finc (neregistrovaný)Co se tyce toho default konstruktoru, tak pokud zadny nespecifikuji, prekladac preci definuje defaultni, tedy verejny, bezparametricky konstruktor.
Co se tyce te serializace, tak ta je potrebna pouze pro objekty, ktere jsou navratovou hodnotou danych business metod. A to jeste v tom pripade, ze se jedna o distribuovane objekty, tedy, ze se posila z jedne JVM do druhe. -
Pavel TišnovskýZlatý podporovatelNo taky v pripade, ze se provadi redyploying (to je teda slovo :-) a chceme si zachovat vsechny objekty ulozene v session+par dalsich veci. Ja to zminoval z toho duvodu, ze se na ty dve slova implements serializable nekdy zbytecne zapomina a potom se to musi resit az o dve-tri urovne vyse, coz muze byt problem.
-
Do javy ani beans nevidim, ale kdyz je ta instance stateless, k cemu serializace krome potvrzeni jeji existence? A kdyz jde jenom o potvrzeni existence instance, proc to neudela nejaky default serialize. A/nebo kdyz instance neexistuje, nevytvori se automaticky nova, a pak vzhledem k stateless bude vsechno koretkne fungovat protoze bude rovnocenna s tou byvalou?
Jinak celkove ... diky za prehled, mne to prijde tak nejak zbytecne slozite cely AP+SOAP+... ale treba tomu diky temto clankum nakonec prijdu na kloub a pochopim kde se to hodi pouzit. :) -
Bretislav Wajtr (neregistrovaný)Nejsem si jisty jestli JBoss opravdu povoluje vyjimku mit jeden interface oznaceny jako @Remote i @Local. Alespon ve verzi 4.2.2.GA na ktere zkousim EJB3 to urcite nejde. Jestli je to v petce uz mozne, tak to budu muset jeste vyzkouset :). Nicmene jina cesta jak obejit tento problem, je definovat jediny interface pro remote i local, u ktereho ale nespecifikujeme nic (tedy zadnou anotaci, pouze hlavicky metod) - ale nadefinujeme si to az na samotne beane, cili napr takto:
@Remote(StatefullComponent.class) @Local(StatefullComponent.class) @Stateful public class MyEJBBean implements MyEJBBeanInterface { public String getGreeting() { return "hello"; } }... a toto reseni vyhovuje i specifikaci, takze zadna vyjimka neni nutna... -
finc (neregistrovaný)Rekl bych, ze uvnitr JSP by to byla dobra prasecina, ani me nenapadlo to zkouset :) Na druhou stranu, i z JSP stranky se nakonec stava servlet, takze proc ne? :)
Uvnitr weboveho kontejneru urcite. Co se tyka "na strane klienta", zalezi jestli klient je v jine JVM ci nikoli.
Podle toho, co jsem zkousel ja, tak jedina moznost je uvnitr "Main classy" (tridy, kde je main metoda a "lukapuji" (pekne slovo) remote interface), alespon tak je to prezentovano pro EJB3 :)
Jinak klasicky pres InitialContext.lookup.
V JBoss AS nejsem az takovy znalec, ale jak je to s JNDI kontextem? Napriklad uvnitr glassfishe, kdyz chci ziskat nejakou EJB beanu jinak, nez pres @EJB (DI), ale pres Context.lookup, musim specifikovat JNDI v anotaci @EJBs nad danou komponentou. -
antaran (neregistrovaný)vsak to...skusal to vobec niekedy niekto? Pokial ide o jboss tak mne DI fungovalo v servlete na nejakej 5 beta verzii na 4.x mi to neslo...
v JSP som to neskusal vobec, ale mam silne pochybnosti...uz si presne nepamatam, ale zda sa mi ze EJB 3 specifikacia to asi ani pre JSP stranky nepozaduje
kazdopadne ak sa to niekomu bude chciet vyskusat mohol by napisat ako dopadol
to ze je mozne nadefinovat DI nad classom a lookapovat ho rucne v specifikacii je, ale to ze nieje mozne urobit lookup bez zadefinovania tejto dependency je pre mna novinka -
YF (neregistrovaný)mohl by mi autor vysvetlit proc sem neda proste link na JEE tutorial kde je vse vysvetlene v kontextu a nerekne ze tohle umi kazdy aplikacni server tedy i jboss - coz je take mezinama jedna z hlavnich vyhod
http://java.sun.com/javaee/5/docs/tutorial/doc/
Ono ukazovat tyhle veci na jbossu - a kdyz si to pak nekdo bude chtit vyzkouset tak se ztrati nekde v deploymentu a ja nevim v cem jeste - pokud nechape aspon trosku JMX tak stejne nepochopi v cem je jeho hlavni vyhoda a s toho pak poplynou akorat takovyty klasicky kecy jakoze 'vzdyt je to cely nepouzitelny a nacoto vlastne je' - proc proboha zacinate jbosem kdyz by stacil 'jednoduchej' glassfish kterej je v tutorialech pouzivanej i s fungujicima examplama -
YF (neregistrovaný)tak jako pokud vam de o clanky pro clanky navic jeste uplne vytrzene z kontextu - tak to je podle me absurdnost - udelat jeden clanek kde se shrne kontext (trebas i jenom za pomoci odkazu) mi prijde daleko efektivnejsi nez plytvat casem a prostredky a ve vysledku stejne prijit s necim takovymdle .. atd atd no a tak - jinak slibuju ze uz se k serii techdle clanku nebudu vyjadrovat :)
-
Radek Hladik (neregistrovaný)Naopak, ja jsem za tenhle clanek rad. Navic v diskuzich pod minulymi clanky o JBossu bylo autorovi vytykano, ze vubec neukazal, k cemu to vlastne je a jak to funguje, ze by bylo vhodne ukazat nejaky Hello World. A tady to je a zase nekdo nechapave krouti hlavou.
Po dlouhe dobe prinosny clanek. -
ufak (neregistrovaný)Ja to treba privitam.
Rychle obecne seznameni s tim, co AS poskytuje. V cestine si to prectu rychleji.
Jen nebudu vedet, ktery AS mam pouzit v budoucnu, bud prvni, ktery jsem se ucil, protoze uz to s nim znam (zatim teda ne), nebo nejaky, ktery mi nekdo z politickych duvodu naridi.
Ja obecny tutorial v cestine uvitam. Jak krok za krokem vyzkouset zakladni veci. Speciality uz clovek najde v manualech, forech nebo se protluce... -
LENIN POWER! (neregistrovaný)Hibernate zavre result set a pak chce pristupovat k LOB objektu. Vyvojari by zaslouzili nakopat.
Ano v mysql a pgsql to projde.
Ja se rad hibernate zbavim, vetsina problemu s db pristupem aplikaci co tu mame je zpusobena prave hibernate. Taky se hibernate netvari jako ze by chcelo pouzivat update locky (select XXX FOR UPDATE) a je timpadem nachylne na race conditions.
Jsem ochoten vyzkouset a provozovat jakoukoliv technologii, kde bude alespon teoreticka moznost mensi zabugovanosti nez v hibernate. -
> Hibernate zavre result set a pak chce pristupovat k LOB objektu.
Mozete to specifikovat blizsie ? Nenarazil som zatial na tento problem ( pouzivam Informix ).
> vetsina problemu s db pristupem aplikaci co tu mame je zpusobena prave hibernate.
No vacsina problemov s ktorymi som sa ja stretol pri pouzivani Hibernate bolo o tom, ze programator sa snazil ohnut Hibernate na svoj obraz a ignoroval doporucenia tvorcov Hibernate ( napr. session pre request ). Je to akoby som si kupil Rolls-Royce a potom by som na nom vozil piesok ..., da sa to, ale nemozem sa potom stazovat, ze ten Rolls ma slaby vykon a casto sa kazi.
> hibernate netvari jako ze by chcelo pouzivat update locky (select XXX FOR UPDATE)
Ak by som chcel pouzivat SELECT-FOR-UPDATE, tak pouzijem session.load/lock/refresh(...,LockMode.UPGRADE).
Ja vsak radsej pouzivam verzovanie pre jednotlive objekty, vyhnem sa tym dead-lockom.
> kde bude alespon teoreticka moznost mensi zabugovanosti nez v hibernate.
Netvrdim, ze Hibernate je bez chyb, urcite sa mi vsak zije s Hibernatom lepsie ako bez neho ( najma ak si tie chyby dokazem opravit ). Na skusanie inych alternativ, bohuzial nemam cas.
ČLÁNKY DO MAILU