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.

Appszerver deatmatch Part 1

Van még egy elmaradásom. Szóval a legutóbbi Java User Meeting-en lement az Appserver deatmatch első része, azaz a Sun ingyenes Glassfish v2 szerverét nyüstöltük. Azaz nyüstölte két hozzáértő ember, egy előregyártott "vendégkönyv" ejb-webes alkalmazással, mi pedig figyeltük a kivetítőn ténykedéseiket. Nézzük a nyolc feladatot:

1. Egy EJB3 + JPA alapú egyszerű webes vendégkönyv alkalmazás beüzemelése a gépre telepített adatbázissal, bónuszként a benne lévő webszolgáltatás WSDL-ének letöltése.

Hamar ment, rögtön a második részt is kipipálva. Belenéztünk a WSDL-be (csúnya nagy XML, lényeg hogy automatikusan generálódott) és csináltunk egy teszthívást a Glassfish admin konzol segítségével. A teszthívás azt jelenti, hogy kitöltögettük a Glassfish WSDL alapján dinamikusan generált HTML formját és submitáltuk.

2. Build script-ből (távoli) deploy.

Netbeans-ből nyomták Ant-tal egy speciális Glassfish task-kal. Tehát nem sima másolási műveletről volt szó, bár úgy hallottam támogatja a hot-deploy-t is, azaz pár másodpercenként szkennel egy könyvtárat és ha talál változást benne akkor újradeployol.

3. Loggolási konfig megváltoztatása egy alkalmazás alatt futásidőben.

Ezt is az admin konzolon lehetett megcsináli és a logot is ott néztük csilivili táblázatban. Szokásosan loggerenként lehet severity level-t állítgani. A példaalkalmazás ilyen szempontból hazabeszélős volt, mert épített arra, hogy a Glassfish admin konzolja a Java Logging API-t támogatja (és csak azt). log4j konfigot gondolom a log4j.xml kézzel való szerkesztésével lehetett volna állítgatni és a csilivili html táblázatról is le kellett volna mondani, de ennek mégis jobban örültem volna.

4. A vendégkönyv távoli debug-olása.

Ez is simán ment, de a Glassfish-t újra kellett indítani a Debugolás megkezdése előtt. Úgy rémlik a JBoss-t nem szoktuk újraindítgatni, fixre be van állítva neki egy kapcsoló hogy engedélyezi a debug kliensek csatlakozását. A kapcsolót persze nem lehet menet közben váltogatni. Netbeans volt a debugoló kliens, de más is lehetett volna, mert standard debug portot használ.

5. Adatforrás megváltoztatása futásidőben.

Ez nem ment (exception), bár nem is vártuk el. Szerintem semmelyik alkalmazásszervernél nem működik. Az alkalmazás újraindításával viszont már simán ment. Ezt is az admin felületen állítgatták.

6. Appszerver leállítása majd újraindítása a deployolt alkalmazással.

Ezt észre sem vettem. Nem mértünk időt, de 10 másodperc körül lehetett sacc per kábé.

7. LDAP azononosítás (ha belefér az időbe)

Ez sikerült volna, de már kezdtünk kicsit kicsúszni az időből. Az mondták 10 perc alatt megvan általában, még 2 perc kéne (8 perc eltelt akkor).

8. Terheléses teszt (JMeter)

Terheltünk, 1700 request/sec-en ketyegett egy átlag notebook-on. Már nem emlékszem a pontos számokra, de tuningolással talán fel tudták vinni 2200-re. (JVM paraméterek.) A terhelésnél a loggolás ki volt kapcsolva és a debug mód sem működött. Ennek a pontnak akkor lett volna értelme, ha azonos hardveren van mivel összehasonlítani, így magában nem sokat mond.

Nagyon jól felkészültek voltak a srácok. Kíváncsi vagyok a többi versenyzőre 2 hónap múlva. Remélhetőleg felveszik a kesztyűt és ők is komolyan veszik a dolgot. Továbbá előtte kipróbálják azért a tesztalkalmazást, esetleg megcsinálják benne a szükséges változtatásokat, hogy fusson a saját appszerverükön is.

BEA Weblogic kipróba

Meg kellett néznem ezt a BEA Weblogic java appszervert.

"A www.bea.com -ról regisztráció után letöltheto a Weblogic 9.1-es többféle oprendszerre, köztük xp-re is (356.4mega).
Standard install, a Mercury profiling tools-ot nem installáltam. Így 533mega lett a könyvtárja, még saját JDK-t is felhúzott. A doksija eléggé bőbeszédű. Az a baj hogy nem nagyon választja szét az advanced és a kezdő dolgokat, folyamatosan mellébeszél, így nem tudom hogy mivel kell kezdeni. Nem tudom mik tartoznak az alapvető működéshez.

Standalone Server Domain kell a fejlesztéshez és kipróbáláshoz, amikor az admin szerver ugyanaz mint az applikációt futtató szerver.
A domain konfig fájlot nem szabad módosítani kézzel.
A domain autodeploy könyvtárába lehet pottyantani az ear-t ami magától deployolódik, ha a szerver development módban fut. (Alapból így fut.)

Start menü / BEA Products / Examples / WebLogic Server / Start Examples Server -rel lehet elindítani. Megnyit egy browser ablakot is infókkal miután elindult a szerver. A webes admin konzolra a weblogic/weblogic-cal lehet belépni.

Csináltam egy JDBC datasource-t az alkalmazásunknak, kérdés hogy működik-e. Valószínűleg nem. A teszt azt írja hogy success, akkor is ha elrontom az ip címet.

Próbáltam deployolni a sima ear-t, de nyilván nem sikerült. ClassNodtFoundException-nel elszállt. Az App-inf/lib -be kéne tenni a jar-okat?

Egymás mellé kéne tenni egy sample.ear-t és az myapp.ear-t, majd közös nevezőre hozni.
Az application.xml mellé kell egy weblogic-application.xml amiben fel vannak sorolva a datasource-k vagy mi.
Ennél bonyolultabb a dolog: A weblogic egy életérzés, de nem mondanám hogy tiszta és száraz. Amúgy biztos jó annak aki ért hozzá valahonnan.

Ahogy elindul, a böngészőben van egy "Learn About WebLogic Server" szekció, azon belül "Code Examples and Sample Applications". Ezt fogom most nézegetni, konkrétabban a Stateless Session Bean példát amihez kicsit körmönfont módon lehet hozzájutni.

Először le kell futtatni a domains/wl_server/setExamplesEnv.cmd-t egyébként elhasal az ant build, mert nem találja a wlcompile-t.
Ant build-del lehet buildelni.
A samples/server/examples/src/examples.properties-ben a wls.hostname-t átírva egy távoli gépre is lehet deployolni elvileg. Gyakorlatilag nem sikerül csak lokál gépre."

Eyeket írogattam róla, de cancellálódott a dolog.