Hát, megvan egy ideje, hogy utoljára írtam. Pedig magamban már többször megfogadtam, hogy rendszeresebben írok. Úgy volna értelme csinálni az egészet, hogy hetente legalább egy bejegyzés születik. Persze ez így hiú ábránd ennyi házi feladat mellett.
Ez az UML házi kész volt. 80 órát egy hét alatt beletolni abba, hogyan kell leimplementálni egy hello world-nél egy szinttel bonyolultabb feladatot J2EE alapon, na ez teljesítmény. És örülök, hogy ennyi idő alatt összeállt…
Nem véletlen tartott eddig. Van benne egy gyönyörű implementált objektumrelációs leképezés, néhány tag elhelyezése, egy xml-fájl és még néhány sor kód megírása után az objektumokat szépen kimenti az adatbázisba, illetve visszaolvassa onnan igény szerint. Tényleg szép. Csak az ember el ne szúrja a tagelést, mert olyan exception-trace-t kap futáskor, hogy öröm nézni. A legnagyobb, amit sikerült kapni, 40 kB méretű volt. Iszonyatosan redundáns, gyakorlatilag az egész háromszor szerepel, az értelmes tartalom másfél-két sor. Szűrd ki…
A fejlesztés során mi RAP-t használtunk GUI-készítéshez. Nem gyenge technológia: Eclipse plugineket AJAX-szal támogatott weblapokra fordít. De azért ezt több projektből összefejleszteni szép teljesítmény. Például nem mindegy, hogy hol kapcsoljuk össze a projekteket. Ha az Eclipse projekt tulajdonságainál fogjuk, és beikszeljük a Referenced projects résznél (hogy szerepeljen a build path-ban), az nem jó. A plugin.xml fájlban kell a depencencies blokkban bejelölni.
Remek, most már lefordul, elindul, és gyönyörű exception trace megint. Most az a baja, hogy nem töltötte be a futás közben a hivatkozott projekteket. Némi szórakozás után kiderült, hogy a megoldás az, hogy még a futtatási konfigurációnál is fel kell venni a hivatkozott projekteket, mint bundle-t. Eredetileg ezt nyersen az xml-be hakkoltam bele, később hívta fel valaki a figyelmemet, hogy a futtatási konfigurációnál is fel lehet venni.
Hasonló szépségek vannak az APIban is. A RAP1.1M1 és az 1.1M3 között megváltozott az alkalmazás belépési pontjának szintaktikája: az M1-ben Display típusú, míg az M3-ban int típusú visszatérési értéket vár. Érdemes megnézni a sorrendet, Display-ből int.
Beletelt némi időbe, amíg rájöttem, hogyan kell megváltoztatni a mintakódot, hogy lefusson. Gyakorlatilag a Display egy azonosítóját kell visszaadni a metódus végén. Szóval minden érdekes.
Hasonlóan jópofa volt az, hogy amikor beraktuk a szükséges webservice meghívásához szükséges fájlokat, akkor kb 25-30 MB méretben kellett jar-fájlokat a lib könyvtárba tenni. Ami problémássá teszi a dolgot, hogy ez csoportmunkában készült házi feladat, azaz fel kellett tölteni egy svn szerverre, és a többieknek le kellett szedni. Hab a tortán, hogy az svn csak fájlok között frissíti a status bart, így a 10 megás jarnál úgy néz ki a dolog, mintha meghalt volna menet közben. A csúcs az volt, amikor ezt upload közben sikerült valakinek fagyásnak értelmeznie, és kilőtte az Eclipse-et. Ezután egy órába került, amíg sikerült rendbe tennie a rendszert…
Érdekes ez az Enterprise Java technológia. Ekkora aknamezőt még nem láttam… Elég valami apró hiba, és hihetetlen mennyiségű hiba bukkan fel, és a hibaüzenetekből is alig lehet kikövetkeztetni, hogy mi lehetett az ok. Elég bonyolult architektúra, rengeteg 3rd party lib, és nagyon korlátozott tapasztalat: ez elég ahhoz, hogy a nem túl bonyolult feladat megoldását nagyon megnehezítse.
