Eclipse J2EE támogatás

Kipróbáltam az Eclipse 3.3 J2EE edition J2EE alkalmazás támogatását. Nem nagyon találtam róla épkézláb leírást és csak 1-2 órányi kísérletezés után sikerült kitalálni, hogy milyen sorrendben kell csinálni a dolgokat és tulajdonképpen mi micsoda. A help-ben sokminden van, de egy lényegretörő leírás nincs, hogy "figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást", ezért most lepötyögöm ide.

Figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást:

Először is az Eclipse J2EE edition támogatja appszerverek vezérlését az IDE-n belül. Glassfish V2-t választottam játszásra, ami alapból nincs a támogatott szerverek között, de le lehet tölteni a modult. A konzol view-eknél van egy új fül Servers névvel. Lokális és távoli szervert is fel lehet venni, én lokálban próbálom. Gyakorlatilag elindítani és leállítani tudja a szervert, nem veszi észre a fenn lévő alkalmazásokat és ha Eclipse-n kívül indítom el akkor is zavarba jön. Azt hiszi hogy nincs elindulva és nem találtam olyan funkciót amivel frissíteni lehetne az állapotot - pedig nagyon meg tudnám becsülni. Szóljon aki tud ilyet! Ezen kívül megjelenik az appszerer logja egy konzol ablakban. Ja igen és debugolni is lehet az enterprise alkalmazást.

Leírom nagyjából hogyan néz ki egy ilyen J2EE alkalmazás belülről. EAR-ban vannak JAR-ok, WAR-ok és különböző XML-ek. (EAR, WAR, JAR: kb zip formátum.) Ezt kell bedobni az alkalmazás szerverbe. Ezenkívül lehet külső kliens, ami sima Java, csak még gondoskodni kell egy közös osztálykönyvtárról ami a külső kliens és az Enterprise App közti interfészeket tartamazza. Ez tipikusan egy jar, ami a kliensnél és a szerveren is megvan az EAR fájlban.

Csináljunk J2EE alkalmazást!

New J2EE application project
Target runtime, configuration - maradhat default, de később is még felajánlja. EJB3-as alkalmazást akarok csinálni.
J2EE modules to add - ha vannak más moduljaink. Generate deployment descriptor - csekkeljük be jól jön az.
Van itt egy olyan gomb hogy New module. Érdemes megnyomni mert rögtön felajánlja hogy csináljon-e client, ejb, web és connector modulokat. Engem most a web és a konnektor nem érdekel, azt nem csekkeltem be.
Rögtön létre is hozza a két projektet. (XXXEARClient, XXXEAREjb) Az EAR kliens alatt az én értelmezésemben pl. egy desktop alkalmazást értek *, ami cseszeregteti az EAR-t. JUnit teszteknek kiválóan alkalmas.
Finish. Megcsinálta az EAR-t is, átváltódunk J2EE perspektívába. Ha jól látom nem csinált szabványos ejb-jar-t, -hiába ikszeltem be- csak sun-ejb-jar-t.

Az EJB projekt context menüjében a J2EE menüpont alatt ki lehet választani a create EJB Client jar-t. Ezzel létrehozunk egy újabb projektet, amiben az EJB interfész osztályait tároljuk: business interfészek, kliens és szerver között mozgatott adatszerkezetek, utility osztálok kerülnek ide. Az EAR kliens projektben a J2EE module dependencies-ben be kell állítani, hogy lássa az EJB kliens projektet.

Új EJB3-at csak kézzel lehet létrehozni jelenlegi tudásom szerint.

-Az EJB kliensbe kell felvenni tehát egy interfészt ami a lokális vagy remote interfész lesz. Alaphelyzetben az ejbModule a forrásfolder. Tessék egy business interfész:

public interface ISample51 { //51: ötödik próbálkozásom első interfésze
String helloWorld();
}

-Az EJB projektben új osztály létrehozása Session Bean-nek. A felajánlott interfészeknél láthatóak az EJB kliensben létrehozott interfészek. (Ha elkezdjük írni.)
-Implementálni kell a metódusokat és fel kell annotációzni az osztályt pl. így: @Stateless @Remote public class SLSB1 implements ISample51 { ... } Azért remote, mert az appszerveren kívülről szólítjuk meg.
-Csinálni kell egy kliens osztályt. Már lehet hogy csinált egy Main-t a default package-be, ezt is használhatjuk. Egy ejb megkeresés és hívás így néz ki, ez kerül mondjuk a main belébe:

javax.naming.Context ctx = new javax.naming.InitialContext();
ISample51 hw = (ISample51)ctx.lookup(ISample51.class.getName());
System.out.println(hw.helloWorld());

Ha most futtatjuk a kliens osztályt jól elcsattan NameNotFoundException-nel, mert nem találja a bean-t. Miért is találná, nem deployoltuk. Ha nem lett volna elindítva az appszerver indítsuk el az Eclipse-en belül. Servers fül, play gomb. Deployoljuk: server view, context menü, add and remove project. Átnyomjuk az EAR projektünket a bal oldalról a jobbra, finish. A konzolon egy rövid Ant log jelenik meg. Nálam átlagos gépen 7 másodpercig tart a fenti bonyolultságú alkalmazás telepítése. Ha mindent jól csináltunk hibaüzenetek nélkül ÉS "Application Deployed at..." üzenettel. Vigyázat, ha valójában nem sikerült a deploy, akkor is képes kiírni a deployed üzenetet. Ha most futtatjuk a kliens osztályt, akkor már csinálja a dolgát.

Változtassunk bele az EJB-be minimálisan, buildeljünk újra. Ilyenkor az alkalmazás automatikusan újradeployolódik.

Ha az automatikus buildet beállítjuk, akkor kb. minden mentésnél megtörténik az újradeploy, ami nem valami szerencsés úgyhogy ezt az opciót érdemes kikapcsolni. Vannak még további lehetőségek is a build-deploy kapcsolatban, de ez most ezen a szinten nem érdekes.

Ha az interfészt megváltoztatjuk mondani kell egy olyat az EJB projeknek (a context menü J2EE részében) hogy update EAR libraries. Úgy emlékszem hogy bizonyos beállítások mellett erre nem volt szükség. Igen: Az EJB projektben a J2EE module dependencies-ben ki kell ikszelni a client-jar projektet.

* A Wizard által generált EARClient nem biztos hogy az aminek gondoltam, mert ha beleváltoztatok az maga után von egy újradeployolást. Márpedig ha a külső klienset változtatom miért kellene újra deployolni a szerver alkalmazást? Inkább csináltam egy új sima java projektet a külső kliensnek, amibe beimportáltam a J2EE library-t és felvettem függőségnek az EJBClient projektet. Így már jobban működik.

Dióhéjban ennyi. Közben még találtam egy hasonló -képekkel is illusztrált- leírást itt, JBoss-hoz. Ha pedig kinyitom a csapot, az jön belőle hogy hogyan kell Netbeans-szel Glassfish alá J2EE alkalmazásokat csinálni. Homokozásra jó ez az Eclipse-be integrált módszer, de semmiképpen nem ajánlanám komolyabb alkalmazások fejlesztéséhez. Többször is okozott meglepetéseket az IDE ha véletlenül összekavartam a dolgokat, pl. nem volt hajlandó buildelni. Tekintve hogy integrált buildelésről volt szó, nem tudtam mit csinálni csak találgatni vagy új workspace-t nyitni. Ant-os fejlesztésnél ilyenkor megjavítom a build scriptet és kész. Az Eclipse-ből kiemelve a projektek használhatatlanok, mert nincs bennük semmiféle build script. Próbáltam így importálni külső J2EE projekteket igazán kevés sikerrel. Ha már itt tartunk meg kell említeni a Maven plugint, amit viszont lehet használni komolyabb J2EE alkalmazásokhoz és a hierarchikus Maven projektek importálása is kiválóan működik.

A javalistán is éppen lett egy hasonló témájú thread az elmúlt napokban, konkrétan JBoss-ra kihegyezve.

JUM IV.

20-30 fős társaság gyűlt össze a novemberi paláveren. Szerintem ez nem kevés, illetve nem lenne rossz, ha a következőn is lennének ennyien. Érdemes eljönni, nem messze van a Lehel tértől. Bp-n, persze.

Android: Rövid, pörgős előadást terveztem, éppen ezért kissé felületes lett. A végén a kérdezős-vitázós-beszélgetős részben viszont elhangzottak azok a fontos részletek is (mástól), amelyek a prezentációba nem kerültek bele. Az előző postban már sokmindent leírtam az Androidos témával kapcsolatban, de még annyi, hogy Midorinál is van néhány hasznos link. A decemberi Budapest Tech Meetup-on pedig szintén lesz egy előadás erről a csodáról.

Glassfish: Megtudhattam, hogy a GF a szabványt maximálisan követő appszerver a JBoss-sal és egyebekkel ellentétben. (A JBoss nem kapta meg a minősítést.) Kommerciális verziója a Sun Java System Application Server. Szép és ingyenes, JSF-en alapuló management konzolja van. Még nem a GFv2, hanem csak a GFv3 lesz a mikrokerneles, gyorsan induló változat. Elhangzott, hogy mégis elég sok helyen JBoss-t használnak. Mi is, viszont én szívesen kipróbálnám a GF-et fejlesztésre. Nem tudom, hogy támogatja-e a következő dolgokat:

• robbantott ear és war fájlok hot deployolása.
• van egy log4j.xml amit szerkesztgetve könnyen befolyásolható a loggolás.

(Tipp: nyilván tudja ezeket.)
Ennyi nagyjából elég is lenne a fejlesztéshez. Az előadás közben elgondolkodtam rajta, hogy mennyire más igények merülnek fel fejlesztés és üzemeltetés közben. Fejlesztés közben nem érdekel a fürtözhetőség, a grafikus konzol felület, hanem inkább az, hogy az iterációs körök minél rövidebbek legyenek. Erre nagy segítség, ha nem kell becsomagolni az ear-t, (hogy az appszerver aztán kicsomagolja magának egy munkakönyvtárba). Esetleg az appszerver csak a valóban megváltoztatott komponenseket nyalja fel újra. Ez még akár azt is jelentheti, hogy a fejlesztés közben nem kell kilépnünk a webes vagy egyéb kliens alkalmazásból, mert megmaradnak a session-ök. Ha jól értettem a Glassfish-Netbeans páros nagyon szépen tudja ezt. Nem hátrány az sem, ha a szervert lehet rángatni Ant taskokkal.

MDA: Azt hittem, hogy az AndroMDA -ban benne foglaltatik az UML diagramok megrajzolása is, de nem. Arról van szó, hogy szabványos UML rajzoló eszközzel megrajzolunk valamit, amiből ez a program különféle sémák alapján legenerálja a programkódot. Sémákat (vagy cartridge-eket) mi is gyárthatunk (Velocity ), viszont mindenkinek megvannak a saját jól bejáratott sémái a fiókjában, amit nem oszt meg másokkal. Mint kiderült, kevés a jó és szabványos UML generáló eszköz. Felmerült az OmondoUML Eclipse plugin, amivel már régen találkoztam, de annó annyira nem tett rám mély benyomást, hogy huzamosabb ideig használjam. Az AndroMDA végső soron egy konzolos eszköz, amit Maven -nel lehet működtetni. A kódgenerálás utáni változtatások itt is problémát jelentenek, mint mindenhol. Ha átírjuk a kódot, ő új kódgenerálás után szépen felülírja. Persze vannak olyan részek, amiket elvileg nem ír felül. Java mellett bármilyen nyelvre tud fordítani, ami a sémáktól függ -ennyivel több az integrált eszközöknél. Eclipse-szel, Hibernate-tel és JBoss-sal a legérdemesebb használni de a demó során éppen Netbeans-Glassfish-Toplink(?) használatot láthattunk -akadtak is emiatt kisebb gondok. A javakocsma, avagy a javaforum2.0 is ezzel az eszközzel és az imént említett technológiákkal készül. (A Glassfish-nek gondot okoz a javaforum2.0.ear fájlnév.) Az a véleményem is megerősödött, hogy hatékony UML szerkesztéshez iszonyat nagy monitor kell.

Szóba jött még, hogy mi itt egymás között szépen pajzsra emeljük a szimpatikus java-s eszközöket, miközben a "nagyok" hazai terjesztői többnyire arra törekszenek az általuk avanzsált termékek népszerűsítésénél, hogy minél kevesebb munkabefektetéssel megszabaduljanak a feladattól -legalábbis néha úgy tűnik.

Netbeans 6 pre kipróba

Kipróbáltam a 6-os netbeans preview-jét, de előbb egy kis történelem.

Annak idején JBuilder-rel kezdtem, majd NetBeans-re váltottam, mert ingyenes, teljesen java, platformfüggetlen és frankó volt. Aztán a munkatársaim ajánlották az Eclipse-et, mert látták hogy a NetBeans-szel kicsit döcög a gépem és mindig egyszerűbb szoftvert cserélni, mint hardvert bővíteni. (Nem azért egyszerűbb szoftvert cserélni, mert nehéz beletenni a gépbe plusz X mega RAM-ot, hanem mert ezt meg is kell szerezni valahonnan, el kell menni érte, szét kell szedni a gépet (ami kockázat) és fennáll a veszély, hogy a többieknek is hirtelen szükségük lesz bővítésre.) Tehát igaz hogy az Eclipse nem full java és nem teljesen platformfüggetlen, de kevesebb memóriát igényelt és ezért az alkalmazásváltások nem okoztak nagy szürke képernyőket pár másodpercig. Döcögős volt az átállás, de most (pár évre rá) már teljesen megszoktam és megszerettem. Néhány projektben nem is tudnánk mást használni, mert erre vannak meg azok a pluginek amik nekünk kellenek.

Mostanában nagyon nyomják a Netbeans-t. A Sun konferencián is külön előadást kapott (Roumen volt az előadó). Minden elképzelhető dolgot beleintegrálnak a MIDP grafikus GUI szerkesztőtől kezdve a Ruby támogatáson és a JSF GUI szerkesztőn keresztül a JBI-ig. Csak azt nem tudom hogy a fejlesztők hány százalékának van ezekre így együtt szüksége. Valószínűleg 0, szóval a dolog inkább a marketingnek szól.

Ha megnézem a hamarosan megjelenő Eclipse 3.3-as feature listáját, akkor pedig csupa csip-csup dolgokat látok, amiket valószínűleg észre sem vennék egyébként, de kódolás közben igazán hasznos lehet egyik-másik.

Egy éve volt szerencsém a Sun Java Sun Enterprise 8-hoz ami a Netbeans-ra épül és nem dobtam hátast tőle -konkrétan egy nagy rakás szerencsétlenség volt, úgyhogy talán némi szkepticizmussal vágtam bele a 6-os preview kipróbálásába.

Az installálás és az indítás oké. Mellesleg közben kicseréltem alatta a Java-t 5-ösről 6-osra és ezután nem volt hajlandó elindulni, a beállítást pedig nem tudtam megtalálni, tehát gyorsan újrainstalláltam.

Úgy gondoltam hogy kipróbálom a MIDP alkalmazásfejlesztőt -úgyis most vettem egy frankó Nokia 6300-ast, csinálok rá valami kis progit. Első körben a flow diagram nagyon meggyőző, csak amikor szaporodnak a képernyők (4 fölé) akkor már nem nagyon lehet őket értelmesen elhelyezni. Az összekötő vonalak mindig a képernyő ugyanazon (jobb) oldaláról indulnak és ugyanazon (bal) oldalára érkeznek, ezért max egy wizard szerű képernyő flow-t lehetne belőle szépen összerakni. Bizonyos command-okhoz tartozó vonalak meg sem jelennek. A képernyőszerkesztő nagyjából oké. A generált kód -mint mindig- hagy maga után kívánnivalót. A NetBeans sajátossága, hogy a generált kódba nem enged belenyúlni, nem engedi szerkeszteni. Mindenhol lazy inicializálást használtam, ami azt jelenti hogy csak akkor hozza létre a kontrollt ha szükség van rá és ha már létrehozta, később azt a példányt használja (singleton pattern). Viszont nem tudtam berakni semmi közös részre azokat a kódrészeket, amik a kontroll egyéb tulajdonságait megváltoztatnák másodszori és többedszeri megjelenítéseknél. Tehát minden egyes helyre be kellett tenni a kontroll megjelenítés után, és ez csúnya. Pl. ha egy képernyőre öt helyről lehet bemenni, akkor öt helyre kellett betenni a képernyőt friss adatokkal feltöltő kódrész hívását.

A kódszerkesztő talán azért tűnik szokatlannak, mert nagyon a kezemben vannak már az Eclipse shortcut-jai, de néhány kódkiegészítés azért mellen ütött. Eclipse-ben statikus metódusba eleve nem lehet beírni a "this" referenciát, mert aláhúzza hibának. NB-ben be lehet írni, sőt felajánlja utána a statikus metódusokat is (ctrl+space), amiket ha kiválasztok persze már fordítási hibát jelez. Ha kivételt dobó kódrészt akarok try catch -csel körbevenni és többféle exception-t is el kell kapni, amelyek esetleg egymás leszármazottai, a catch blokkokat néha rossz sorrendben teszi ki, emiatt szintén fordítási hiba keletkezik. Közben a try catch-en belüli kódot is átírja úgy, hogy kiírja az osztályok nevét a teljes package névvel függetlenül attól, hogy az import megvan. Még egy refaktorolási diszkrepanciával találkoztam amikor véletlenül sikerült azonos nevű osztályokat kialakítanom különböző csomagban. Utána fél óráig kellett böngésznem a kódot hogy visszacsináljam. Tehát a kódszerkesztő, kódkiegészítő, refaktorolós rész leírta magát nálam.

Még a buildelésről pár szó: a MIDP projekt létrehozásánál a Netbeans megcsinált mindent ami egy ilyen projekthez kell, a buildelés pedig gyakorlatilag egy Ant script futtatásából áll. Ez szimpatikus. Az Ant script viszont nem fut valami gyorsan és az emulátor sem ugrik fel túl hirtelen (20 mp egy 2G RAM-os Centrinoval) de azért használhatónak titulálható.

Valamelyik Javaposse-ban hallgattam, hogy az Eclipse inkább hackelésre, kódvarázslásra jó, a Netbeans pedig prototípusok gyors összedobálására. Maximálisan egyetértek. Végszónak annyi, hogy ismét az a benyomásom mint az SJSE8-nál, hogy még mindig kicsit összetákolt dologgal találkoztam, de már sokkal jobb, és kíváncsian várom az igazi 6-os verziót. Hajrá Prága!

Idea

Hallottam erről az idea nevű fejlesztőeszközről az egyik ismerősömtől és ettől függetlenül a JavaPosse -ról is letöltöttem egy hallgatható cikket ami éppen erről szólt.

Azt mondják hogy marhajó fejlesztőeszköz, mert nem az van a központban hogy moduláris, univerzális meg mittudomén milyen legyen, hanem hogy jól lehessen benne jávában fejleszteni és kész. Állítólag jó a refaktoringja, ennyit tudok róla biztosan mondani. 100 dollárba kerül (vagy százezer forint?), 30 napos a próbaverziója és Prágában fejlesztik -mondjuk ez a legjobb pont. Állítólag a Netbeans-t is Prágában fejlesztik (véletlen egybeesés) de lehet hogy valamit félreértettem.

Majd lehet hogy kipróbálom.

SJSE8: nem.

Lassú az UML diagram rajzolás: jó. Néha nem generál le egy-két osztályt vagy metódust: nem annyira jó, de majd résen leszek. De amikor figyelmeztetés nélkül töröl osztályokat, akkor már azt mondom hogy eddig és ne tovább. Hogy nyert ez díjat? Kénytelen vagyok korrupcióra gondolni. Újrarajzolok még pár UML diagramot amit kénytelen voltam törölni most, aztán vissza az Eclipse-hez. A szépreményű Sun Java Studio Enterprise 8-t pedig eltemetem egy felszántott és sóval beszórt virtuális mező közepére.

Java Studio Enterprise 8

Letöltöttem a sun.com-ról a címben említett szoftvert, ami egyébként kb 2000 dollárba kerülne, de most SDN tagoknak ingyen van. Ez egy NetBeans 4.1-re épülő fejlesztőkörnyezet ami támogatja az UML-t.

Beimportáltam az egyik projektünket és elkezdtem diagramokat rajzolgatni. Az a helyzet, hogy egy közepesen nagy diagramnál olyan szinten belassul az IDE hogy gyakorlatilag használhatatlan. (Pentium 4 2Ghz, 512M RAM) 10 másodpercekig kell várni hogy arrébb húzza a komponenst amit drag and drop-olok. Sequence diagram esetében néha elcsúsznak a függvények, Class diagram esetében pedig nem hajlandó néha legenerálni a metódusokat a java osztályokba. Viszont szép antialiasing vonalakat és betűket rajzol, valamint tónusozott dobozokat. De minek. Nekem bőven elég lenne ha 4, max 8 irányban haladó vonalakat tudna rajzolni, csak legyen gyors. Ez a Collaboration sem értem hogy minek bele. Vannak elég jó chat szoftverek.

Bőven van bug report is róla. szerintem azért rakták ingyenesre mert egyszerűen nem éri meg az árát. Szerintem nem éri meg az árát. 1 óra alatt kb 30 perc a szopás -ebből ki lehet számolni hogy mikor kezdi el megérni egy pénzes szoftver.

Megnéztük még a www.omondo.com eclipse pluginjét is. Ez viszont már pénzes és elég borsos az ára. Azt nem tudom mennyire barátságos az IDE, nem foglalkoztam vele sokat mert a JSE8-ra koncentráltam.