Java Ee Entity Exceptions

Java

Sziasztok!

Szeretnék kérni egy kis segítséget Java EE entity kezeléssel kapcsolatban. Próbaképpen írtam egy kis Servletet, ami példányosít egy entity-t id alapján. Az a gondom, hogy ha olyan id adok meg, amilyen entienty nem létezik, nem dobódik exception és továbbmegy a kódom és a megjelenítésnél elszáll mondván, hogy "org.apache.jasper.JasperException: An exception occurred processing JSP page /NewsService.jsp at line 23". Persze be tudok tenni egy ellenőrzést, de nem hiszem, hogy ez lenne az elegéns megoldás, mint inkább az, hogy ilyen esetben egy Exception dobódik. Az entitást egyébként (Netbeans) jobbgomb->New->Entity classes from DataBase menüponttal hoztam létre, tehát alapértelmezett CMP entitás.

Előre is köszönöm a kiigazítást.

Üdv.

  • 1591 megtekintés

( NagyZ v | 2009. 01. 22., cs – 22:11 )

valami kodot muti mar, hogy ered el :)

ha tudod az idjet, akkor a 


EntityClass entity = em.find(EntityClass.class, primarykey);

if(entity == null) {
   ...
}

kod a baratod, ahol em az EntityManager egy peldanya.

ha nem igy csinalod, akkor nem tudom mit csinalsz, muti kodot.

try {
String getId = request.getParameter("id");
if (getId == null) {
throw new Exception("Indefinied ID!");
}
NewsHandler newsHandler = new NewsHandler();
news = newsHandler.getById(Integer.parseInt(getId));

//ez a csúnya rész amit ki akarok gyomlálni
if (news.getBody() == null) {
throw new Exception("Entity not found!");
}
} catch (Exception e) {
request.getRequestDispatcher("/404.jspx").forward(request, response);
}

oo. mi az a NewsHandler? :)

ha entitasaid vannak, akkor altalaban azt egy EntityManager kezeli, tehat valahol egy olyanodnak is kell lennie. milyen JPA implementaciot hasznalsz? mi az entitasod kodja?

en ugy latom, hogy a getBody mar a Te sajat fuggvenyed (marha a getById() egy entitast ad vissza.. de ilyet nem lattam JPAban.)

A NewsHandler egy burkoló akart lenni az Entity Managerhez, persze ez lehet valami rossz beidegződés. Az News entitás így néz ki. A "getBody"-t a netbeans hozta létre az adatbázis alapján. Erre a kérdésre "milyen JPA implementaciot hasznalsz" az helyes válasz, hogy org.hibernate.ejb.HibernatePersistence?

Köszi

Hát akkor akarok, de mint látod még lowwagyok, és nem tudom mit érdemes és mit nem. Sajnos/szerencsére van egy rakás megszokásom is már lásd NewsHandler. A Szoftverfejlesztés Java EE alapon című könyvből próbálom a mozaikokat összerakni, amin mint írtad ne megy szerencsés választás, ahhoz képest egész jól megy :D

vaaaaaaaaaa. ez milyen netbeans?

az entitybeanbe rakja bele a BL -t?.. ez olyan springes. :)

en kulon stateless EJB -be szoktam rakni ilyeneket, pl oda szoktam injektalni egy EntityManagert, es ott beburkolni ezt a getById() -t. persze igy is lehet, ez ilyen izlesek es pofonok dolog ;-)

(kozben latom, hogy kezzel hozod letre EMF -bol. miert nem hasznalsz vmi kontenert? pl glassfish.)

ha a getById() eredmenye null, akkor nem volt ilyen entitas a dbben, ha nem null, akkor maximum az adott mezonek nincs erteke, de az entitas letezik.

"kulon stateless EJB -be szoktam rakni" Az EJB-t még nem értem annyira, és elég kísérleti stádiumban állok a tanulásban is.
"kezzel hozod letre EMF" ezt még nem értem, amúgy Tomcat-et használok, mert
1. régről legalább van némi tapasztalatom vele
2. ez egy backend rendszer lesz, a frontendet meg Openlaszlóban szeretném legyártani, ami szintén Tomcat-en fut.
Persze mindenről meg lehet győzni ;-)

Köszönöm.

namost, par dolgot ugy erzem helyre kell rakni.

a tomcat "csak" egy servlet/jsp kontener, semmi tobb. ez a Java EE egy nagyon kis szelete..
a Glassfish tudja ezt IS, es meg csomo mindent (mindent, amire Neked szukseged lehet): sevlet, jsp kontener is, tud jsft is, es van benne ejb kontener is.
ha az openlaszlo "jo", akkor mindegy, hogy gf -re vagy tomcatre deployolod a warjat: ugyanugy fog futni.

a backend rendszereket nem servletekben szoktak megvalositani, hanem inkabb EJBkben: pont erre talaltak ki oket, hogy a megfelelo business logicot ide lehessen elhelyezni, es elerhesd a kulonbozo retegekbol (taghandlerbe pl tudsz injektalni DIvel EJBt). ezert szoktam en ezt szolgaltatasi retegnek csufolni, ha szobakerul.

nezd meg a diaimat, az nagyjabol vegigmegy a teljes Java EE specen, marmint, hogy mik vannak benne :)

"a tomcat "csak" egy servlet/jsp kontener", nem írtam ugyan de volt egy olyan elgondolásom is, hogy az egyszerűbb felöl haladok a bonyolultabb felé, és (a dolgok jelenlegi állása szerint) eddig kielégítette igényeimet, persze akkor hagyom a csudába, és belecsapok a tutiba.

"ha az openlaszlo "jo", akkor mindegy" igazából az egy megbütykölt Tomcat, és nem csak egy war fájl, viszont ahogy nézem 5.0-s szóval nem úszom meg, hogy 2 szervert is be kelljen üzemelni ehhez a projektjez.

"backend rendszereket nem servletekben szoktak megvalósítani" jelenleg xml-rpc-re gyúrok, ezt gondoltam elég jsp-vel megvalósítani, "NewsHandler"-ek helyett pedig a fentebb beszéltek alapján ejb-ket rakni. Később SOAP-ra van szükségem.

"nezd meg a diaimat" már félig áttanulmányoztam, nagyon jó, és várom a könyvet is.

Köszönöm szépen.

Minden akalmazasszervernek van, webcontainer-e(ami lehet tomcat is), meg EJB containere-e, de ezek szepen ossze vannak drotozva benne, de mukodnek kulon is. Egy jboss-ra, vagy GlassFish-re feltelepithetsz egy war-t is, meg ear-okat, bar ejb3-al csak jar-ok is jok. Egyebkent ejb3-al sokkal konnyebb mar a fejlesztes. Mint mar azt NagyZ mondta szoktak egy vekony Stateless SessionBean EJB reteget huzni a a JPA fole, kb olyat mint a te NewsHandler-ed, ezekben vannak implementalva az adott Entity-k hez tartozo query-k,create, store methodusok, ezek fole szoktak egy komolyabb szinten Stateless SessionBean facade reteget huzni, amiben a konkret uzleti logika van implementalva, egyszeru CRUD alkalmazasnal ez se szokott nagyon bonyolult lenni.

Amugy meg ha mukodne is, sem ajanlatos kigyilkolni az ellenorzo kodokat. Tapasztalatom szerint sokkal intelligensebb hibakezelest lehet megvalositani, ha a bizonytalan outputok figyelve vannak mar a modellben. Ugyan en nem J2EE-ben csinaltam ilyesmiket, de bizonyos dolgokra jo odafigyelni.
Amugy meg, a exception dobasanak ebben a kontextusban nem sok ertelme van, inkabb menj rogton a 404 forwardra.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ja, ertem! Az ellenorzes volt a plusz. Hat, ennek csak egy baja lett volna: ha mukodik. Ugyanis a find elvben akarmilyen exception-oket dobalhat (ertem itt ezalatt, hogy az adatbazistol is felboffenhet idaig valami exception), es azert nem mindegy, hogy 404-et, vagy 500-at dobunk - nekunk info, a kliens szamara pedig ertelmes bugreport lehetoseg.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

nana, ez itt nem allja meg a helyet. ez nem rails ;-)

a perzisztencia reteg findja vagy megtalalja amit keresel, vagy nem. nincs semmi mas exception. nem is lehet.. :) hiszen minden ami a dbbe lekerul, managed. a db csak egy persistence store, igazabol nem is kene db, lehetne barmi mas is.

Kiveve a 'MySQL server has gone away' tipusu hibakat, ami konkretan akkor jon elo, amikor valamiert kirantjak a connect meg a query kozt a mysql szerverbol a dugot. Ha ezt a rendszer minden tovabbi komment nelkul benyeli, az egyfelol jo, masfelol meg nem jo. Jo, mert erre nem kell tervezni a user kodban, es rossz, mert nem lesz igazan info mitol van allandoan 404.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.