Java 7 újdonság szavazás

A Whiteboard játék úgy néz ki, hogy kitesznek a konferencia előterében néhány táblát, amin néhány kedvcsináló kérdés van, és aztán mindenki firkál oda. A TSSJS Europe-on, ahol voltam nyáron, ott három ilyen tábla volt, és a közönség nem is nagyon kapott rá. A JavaPolis-on a fotó alapján más a helyzet. (De majd Kocka remélem beszámol részletesen is).

Az egyik ilyen táblázaton a Java 7 néhány javasolt nyelvi újdonságára lehette szavazni, az eredmények itt. Vicces végignézni, hogy milyen vad dolgokat találnak ki, és néha milyen bután szavaznak az emberek egész értelmes ötletekre. Mintha mindenki rákapott volna, hogy Java7 proposalokat csináljon. Mindegy, felőlem jöhet akármi, de a nulláról Java-t tanulók dolga egyre nehezebb lesz.

JSPWiki

Vegyesek az érzéseim:

Egyrészt iit van a XXI. század hajnalán egy alkalmazás, ami ha nem is csupán JSP-be van írva, de azért úgy tűnik (a kódba nem néztem bele) elmegy minden mellett ami manapság divatos (ORM, Component Based Web Frameworks, stb.), alapból pl. fájlrendszerbe tárolja az adatokat. Tomcat6/Java6-ra telepítés közben elszáll, és mindenféle hekkeléssel lehet csak életet lehelni bele (a legutolsó log4j1.3alpha kell neki, és a properties fájlba a dir-eket be kell állítani.).

Másrészt meglepően kényelmesen és gyorsan lehet használni: mi most egy projekt belső dokumentumait írjuk rajta, és nagyon jól megy. Ráadásul jól kiterjeszthető, pluginelhető, elvileg kis munkával nagyon jó projekt kezdőlapot lehetne fabrikálni benne, ahol együtt látszódnak az aznapi SVN commit-ok és a Bugzillába felvitt tételek. Kiterjeszthető a mögötte lévő tárolási eljárás is, pl. SVN-t is tud használni elvileg perzisztens tárolónak. Ha meg nem akarunk semmi extrát, akkor (ha sikerült deployolni) onnantól tényleg zero config.

GWT widget library

A GWT-hez keresek csilli-villi Widget készletet, ami könnyen kezelhető, és főleg nagyon szép, úgy hogy ha a megrendelő megnézi higyje azt, hogy valami nagyon profi oldalt lát.

Első körben a MyGWT-re és a GWT-EXT-re találtam rá. A demója mindkettőnek (mygwt, gwt-ext) nagyon hasonló. Gugli barátunk viszont azt mondta, hogy a gwt-ext csak egy wrapper csomag, ami natív hívásokkal az ext.js nevű függvénykönyvtárat hívogatja, a MyGWT viszont full Java-ban implementált (és GWT-vel js-re fordított) csoda. Ráadásul a MyGWT-ben vannak olyan containerek (pl. WidgetContainer), amik a Swing-ben megszokott Layout-okat is tudják kezelni, és ezek alapvatően sima Widget leszármazotta, úgy hogy elvileg sima GWT kóddal is jól integrálhatóak.

Szóval egyelőre MyGWT-re áll a zászló, megpróbálom integrálni, és megáltom mi lesz belőle.

Java Café I.

Szóval ott voltam ma délelőtt. Tehát---

Előszőr is a disclaimer: rendszeres és lelkes látogatója vagyok a JUM-nak, ami szintén egy hasonló elvek mentén szerveződő, viszont alulról jövő megmozdulás, tehát akaratlanul is hozzá hasonlítom. Például rögtön első látásra is látszott, hogy a rendezés a szokásos Sun Tech Day-es színvolalon zajolott: elegáns terem, büfé, jegyzetfüzet, toll stb. Körülbelül 40-50 résztvető lehetett becsléseim szerint (mivel volt regisztráció a Sun biztos pontosabb számokat is tud). Az elhangzó kérdésekből úgy tűnt, hogy ezek egy része (mondjuk 10-20 fő) tényleg fejlesztő munkás, és nem csak a managerek jöttek el.

Az előadást Molnár István tartotta, egy szabadon elérhető prezentáció mentén. A szünetig viszonylag általános alapvetés volt (mi is az alkalmazás szerver, miért olyan fasza a Glassfish stb), ezen a részen én egy kicsit bóbiskoltam, (vegyük számításba, hogy az alapvetés engem már kevésbé hoz lázba, illetve, hogy 3 órát aludtam éjjel.) A szünet után már kicsit részletesebb infók is voltak, meg egy hosszabb demó, hogy hogyan is működik a clusterezés. Ez már elég jó volt, már régóta ki akartam próbálni, hogy feltelepítek egy clustert, de valahogy sose volt rá idő, és Molnár István tényleg élvezhetően és profin vezette az előadást, és szolíd marketing mellett sok technikai részlet is elhangzott. Teljesen rendben volt.

A bevezetőből megtudtuk, hogy tényleg egy hosszabb rendezvénysorozatra készülnek, és előreláthatóan továbbra is Sun-os OS termékekről lesz szó (JAX-WS, OpenESB, NetBeans).

Szóval volt, aki rögtön a JUM-hoz hasonlította, ahol persze nincs büfé, nincs póló osztás, és talán az előadók se mind olyan profik és rutinosak mint itt, de valahogy én mégsem érzem, hogy ezeknek most egymás ellen kéne versengeniük. Az egyik ugye délelőtt van munkaidőben, ahová a talpasok csak bonyolult elkéredzkedés útján juthatnak el, a másik meg este, bizonyos pozíciótól felfelé valószínűleg már kevésbé áldozzák fel a szabadidejüket rá az emberek. Viszont szakmaiság azért itt is ott is megtalálható, ehhez az egyik helyen egy felülről jövő céges íz, a másik helyen egy alúról jövő néha kissé amatőr/civil felhang jön hozzá.

Szóval én örülök, hogy újabb alkalom van, ahol Java-ról esik szó, a szakmai színvonalra nem lehet panasz, és látszik, hogy a Sun is tényleg komolyan gondolja. Várom a következő részeket.

Highlight autoboxing

Annó még egy régi interjún nyomták kezemben ezt a kérdést: Milyen i és j értéket tudnál beállítani, hogy végtelen ciklust csinálj:

while (i <= j && j <= i && i!= j) { ... }

A kérdés persze annyira nem bonyolult annak, aki hallott már az autoboxingról, és talán az interjúztató még hintelt is, hogy 1.5-ös Java-ról van szó. Most is csak azért jutott eszembe, mert a NetBeans hírlevél kiemelte ezt a NetBeans plugint, és én meg elgondolkoztam, hogy talán tényleg nem teljesen haszontalan valami szolid highlight-tal jelölni az Unboxing/Boxing eseteket. Különben is egyre szinesebb az IDE-m, szinte öröm leülni elé, akkor már had legyen benne ez is.

ps: a rejtvény egyébként a 2006-is JavaOne TODAY című újságjában jelent meg Neal Gafter and Joshua Bloch cikkében, akik a Java Puzzlers-nek is az írói. A cikk részleteiben és megoldás magyarázattal itt.

ProGuard

Úgy esett, hogy hirtelen java obfuscator kellett volna, és a gugli a ProGuard-ot ajánlott. Teljesen korrekt ajánlat volt.

Az alap obfusator opciók mellett kódot is optimalizál és tömörít is. Hívható ANT taskból, van egy kedves gui felület-e is, ahol az opciókat bizergálhatjuk, majd a beállításokat egy config filbe menthetjük. Tartalmaz egy csomó példát, pl. hogy hogyan lehet egyszerűen megoldani, hogy az obfuscálásból kimaradó osztályokat (pl. public api) annotációkkal adjuk meg, vagy hogy hogyan vegyük a változók neveit a Shakespear összesből. A GUI továbbá tartalmaz egy kedves eszközt, amivel config alapján a stacktrace-t visszaalakítja emberileg olvashatóvá.

Szóval mégcsak egy órája játszok vele, de minden szempontból úri cuccnak tűnik. (Most éppen azt játszom, hogy az Android decompilolásnál is bevált JAD decompilerrel fordítgatom vissza az obfuscált kódot.)

Android a házban

Talán már több mint egy hete jelentte be a Google az Android-ot, ami egy ingyenes mobil platform lesz. (Előtte már régóta találgattak GPhone-ról, de kiderült, hogy hardvert ők nem, csak OP-t csinálnak).

Viszont mától le is tölthető az SDK innen.

Ami miatt lázba jöttem tőle, hogy az SDK full Java alakúnak tűnik. Még nem nagyon szórakoztam vele, de vagy Eclipse pluginnel vagy ant-tal lehet buildelni, van hozzá egy emulator, elég korrekt rendszernek tűnik. Szép Java API. Majd jönnek részletek.

Elhavazva (TopLink kapcsolók)

(Lassan már álmomban is implementálok, de van remény, nem sokára enyhűlni fog a helyzet. És akkor majd...)

Itt viszont egy remek összefoglaló a Toplink JPA suttyom kapcsolóiról. Persze egy része Oracle specifikus, olyan annotációkat meg mégsem akarhatunk látni tiszta JPA forrásban, de egy másik rész pedig szép kiterjesztés, ami kifejezetten belefér a JPA-ba. Pl. vannak plusz propertyk a persistence.xml-be, amik kiloggolják az SQL lekéréseket, vagy hogy induláskor nem az adatbázisba rakja újra a táblákat, hanem elmenti a CREATE SQL parancsokat egy DLL szkriptbe bárhová.

Ha minden jól megy, most úgy is alkalmam lesz mélyebben megismerni a TopLink lelkivilágát.

NetBeans Feature Request

Szóval elmondom mi az az egyetlen dolog, ami hiányzik nekem a NetBeans-ben:

Van ugye a Library Manager. Itt létrehozhatok egy új nevet, és adhatok hozzá 3 dolgot: classpath-t, javadoc helyet, és source-ot. Aztán ha ezt a nevet hozzáadom a project-hez a libraryk közé, akkor a fordítás szépen használja a classpath-t, és az IDE meg használja a javadoc és source helyekről beindexelt információt.

Csakhogy, ha átmegyek egy másik helyre, a másik NetBeans-en ugyanígy létre kell hozni ugyanazzal a névvel a library-t, hogy működjön. Elvileg lehetne azt, hogy csak a JAR-filet adom hozzá (akár property fájlból, akár IDE-ből), de akkor a library meg is lesz a másik helyen (mellé rakom), de a javadoc és a source nem.

A NetBeans-ben pont azt szeretem, hogy ANT alapú és bármit meg lehet benne csinálni. De egy jó hordozható projecthez még ez az egy hiányzik, hogy project property fájlba tudjam definiálni a code-comlpete-hez használandó source és javadoc helyeket.

Glassfish + PHP

Egyik előző bejegyzésemben azt állítottam, hogy hej-de-egyszerű lesz Glassfish-t ellátani globális php értelmezési lehetőséggel. Azt akarom ugyanis, hogy az összes virtual host-on, ha valaki a documentroot-ba másol egy php alkalmazást, az minden további nélkül működjön. Csakhogy a dolog mégse olyan egyszerű

A Resin-ből vidáman kinyerhető a Quercus, a Scripting api-ra is illeszkedő Javaban írt PHP motor, de ezt alapértelmezetten szeretném bekapcsolni. Ezt meg is csináltam: a default-web.xml definiáltam egy servlet-et (com.caucho.quercus.servlet.QuercusServlet) és meppeltem a *.php-re. A sima php ment is, de sajnos a mysq_connect-et már nem sikerült megugrani. A Quercus ugyanis valami megmagyarázhatatlan oknál fogva nem hajlandó sima adatbázis kapcsolatot kezdeményezni, hanem a servlet init paraméterei között meg kell adni egy jdni nevet, és onnantól kezdve a mysql_connect-nek bármilyen paramétert adhatunk meg, úgyis azok helyett inkább a jndi-t használja. Ez egyrészt kedves dolog, mert lehetne PHP-s alkalmazást futtatni connection pool helyett, másrészt elég szar, mert kötelező és egy globális php servlet lehetőségét teljesen ellehetetleníti. Nem lehet/és nem is akarnék az összes hostolt php alkalmazáshoz külön mysql DataSource regisztrációt.

Deployment Toolkit

A Java SE 6 Update N Early Access már elérhető, aminek a része a Deplyoment Toolkit nevű kis játékszer is. Igazából egy .js fájl az egész, ami ad néhány függvényt arra, hogy ellenőrizzük a felinstallált JRE verziót és ez alapján kirajuk az appletet/web start linket, vagy elküldjök a usert java-t letölteni.

Nem néztem át persze a forrást, de az egész csak egy javascriptnek tűnik, amihez nem is kell az Early Access, elég ha befűzzük a html-be ezt a http://java.com/js/deployJava.js -et, és már mehet is.

Itt pl. megmondom neked a JRE verziódat.

<script type="text/javascript" src="http://java.com/js/deployJava.js">
<script>
function detectJRE() {
    var list = deployJava.getJREs();

    if (list.length == 0)
    {
        alert ('No Detectable JREs are Installed');
    }
    else
    {        
        alert (list[0]);        
    }
}
</script>
<a href="javascript:detectJRE()">Itt </a> pl. megmondom neked a JRE verziódat.

A példát innen másoltam ki, ahol további részletek is találhatóak.

Verzió kontroll

Erik Burke írt néhány dolgot, arról, amikor használunk ugyan verzió kontroll rendszert, de valami azért mégse 100-as vele. A gyanús jelek szerinte:

1. Ha a helyett, hogy törölnénk a kódból inkább kommentezünk, hátha még kelleni fog a jövőben. Hülyeség: a verzió kezelő pont arra való, hogy megnézd az előző verziót. (Nálunk ez rendesen be van tartatva, code reviewn nem megy át, ha kikommentezett sorok vannak.)

2. Hetente egy nagy kommit, sok kis helyett. (Nálunk sajnos a rendszer miatt ez van. A clearquest-re ráépített rendszerben egy task = egy kommit, ami akár 40 órás task is lehet. Ha közben másnak is kénének újonnan létrejött fájlok, akkor nincs más mint local copy.)

3. Fizikai backup biztos ami biztos (ami ugye felesleges, mert a verzió kezelő sokkal jobb backupot ad). (Szerintem ez azért annyira nem probléma. Legalábbis nálunk nem fordul elő.)

4. History log: ahelyett, hogy a verziókezelőbe írnánk commitkor mi változott, a fájlok elején txt-be írunk valami log félét. (Abszolút igaza van, nálunk pont ez van, és idegesít is.)

Szóval nálunk a kincstári projektek 4/2 arány érnek el. Lenne még hová...

SJSWS => Glassfish 2

Le kéne cserélni a Sun Java System Web Server-t Glassfishre. Nem csak azért, mert a config deploy a SJSWS-nél bűn lassú (percekig tart), ezt talán be lehetne jól konfigurálni, és nem is csak azért, hogy hódoljak a Glassfish hype-nak, és trendi legyek, de jól jönne egy futó JBI konténer is, és a Web Service támogatása is jobb. A baj csak az, hogy bár a Glassfish végre nagyjából kezeli a virtual hostokat, egy csomó kényelmi szolgáltatás ami webhostingolásnál hasznos nincs benne. Pl. nem lehet jól beállítani, hogy egyes könyvtárakhoz csak jelszóval lehessen hozzáférni.

Az ideális az lenne, hogy ha lenne egy Servlet/Filterem-em, ami értelmezné a .htaccess fájlokat, (legalább mondjuk a jelszós részeket, vagy ne adj isten a ModeRewrite-ot is), és azt be tudnám deployolni default webappnak, ahová kéne. Nem is lenne nagy dolog megírni, csak épp most úgy tűnik semmi időm nem lesz ilyenre. Ha valaki tud ilyenről készen, az ne habozzon szólni (pl. Jettyben láttam hasonlót, csak az nem csak egy servlet, hanem + kismillió függőség, nem nagyon lehet kibányászni).

Ja meg PHP támoatás is kéne, de ez Scripting API-val + Quercus-szal simán szerintem simán menni fog.

Deployer role

A hagyományos JSR speckók mindig ugykezdődnek, hogy szerepköröket definiálnak (Deployer, Application Assembler, Bean Provider) persze sokszor egy ember több szerepkört is megvalósít, ahogy én is a hétvégén amikor néhány percem volt, probáltam egy JCR-es alkalmazást deployolni Sun Web Server és Glassdish alá. Egyik se sikerült tökéletesen (Tomcat 6 alatt remekül fut), úgy hogy debug gyanánt az egyre kiválóbb jcr-explorer-t próbáltam feltenni. Persze azt is sikertelenül.

És itt enyyi, ez egy olyan bejegyzés, aminek nem lesz csattanója. Ha csak nem az, hogy bug reporttoltam (hátha), és a fejlesztő már replayolt is, kössz, hogy szólok, ő JBoss-t használ, és hogy milyen sok szívás van a sok JSF implementáció között.

Így megy ez.

Wicket nyűgök

Na ez tipikusab olyan bejegyzés lesz, ami csak annak érdekes, aki szintén benne van a Wicketben. Két probléma:

1. Ha a WicketFilter-t nem /app/*-ra, hanem /*-ra meppelem, akkor a HomePage-ben a css hivatkozásot (default.css) helyelenul kicseréli egy ../default.cs-re. Ugyanezt az egyenkint felmountolt aloldalakon helyesen oldja meg. Próbáltam bug reportolni, de egyelőre még nem találtam meg, hol a hiba. Workaround: a fő oldalt is fel kell monutolni az Application osztályba valamilyen Bookmarkable címre.

2. Ha Rss-t csinálok ezzel a módszerrel (Gyakorlatilag egyetlen bridge osztály a Rome használatához), akkor nem csak, hogy nem működik, hanem az rss feed helyett kiírja $TOMCAT_HOME/bin tartalmát. Na már most ezt se tudom kinek a hibája (Tomcat/Wicket/Wicket-rome/saját magan), de ez így nagyon durva. Workaround még nincs. Mindjárt megpróbálom Glassfish alatt. (BTW. tudtátok, hogy Glassfish 2 elvileg képes értelmezni deploykor a tomcat-es context.xml-eket?)

Szép URL-ek

Szeretik a keresők, szeretik az emberek, esztétikus jó ilatú, stb. Ilyet szeretnék mindenhová. A vonzódásom története valami ilyesmi:

Hajdan, még Post-Nukés gyerekkoromban volt az index.php?mod=foo&bar=func¶m=1&.... A Front Controller megkereste a foo modult, annak a saját kis frontcontrollere megvalósította a func funkciót, a paramétereket meg beparzolta a funkció.

Aztán jöttek az ügyes apache rewriteok: index.php/foo/bar?par=... csak kicsit szebb, de nem az igazi.

Aztán megismertem, hogy hogyan csinálja ezt a Drupal. A Drupal-ba alapból csak szép URL-ek vannak. Van egy nagy fa szerkezet, és abba egy path egy modul funkció. Ezt pedig szép szorgalmasan fel kel meppelgetni.

Pl. (hasból) a admin/user/rights => admin_user_rights()-hoz lehet rendelni.

A nagy bravúr benne, hogy ha nem talál a megadott path-hoz hozzárendelve függvényt, akkor elkezdi leszedegetni a részeket / jelenként jobbról balra. Pl. a node/edit/22-höz ha nincs rendelve semmi függvény, akkor a node/edit-hez keres (amihez valószínű lesz), és a 22-t átadja paraméternek.

Ebből következik, hogy a paraméterek a drupálban sokszor nem kulcs érték párok, hanem pozíciók. Az ismert meppelés után első, második, harmadik... stb. Szerintem ez mondjuk sokkal szebb és logikusabb mint az előbbi.

Wicket-ben ez úgy néz ki, hogy alapból az oldalak amiket létrehozunk nem kapnak szép URL-t (sőt rosszabb esetben a csúnya url-n se lehet kívülről elérni őket). Hasonlóan a Drupalhoz kézzel a mappinget beállítani (WebApplication.mountShortBookmarkablePage()). A baj csak azzal van, hogy nem a Drupal féle pozíció=> paraméter leképezést használja, hanem a kulcs érték párosat, ami nekem kevésbé tetszik. Igaz ezt hajlandó akár az oldal/param1/value1/param2/value2 alakban is használni (oldal/value1/value2 helyett, amit én szeretnék).

Megoldás: lesszármaztatni a BookmarkablePageRequestTargetUrlCodingStrategy-t és újra implementálni a decodeParameters-t és a appendParameters-t (ezt a szűlőben látott mint alapján nem nagy flikk-flakk). Ezután a mappelést a WebApplication osztályból a

mount(new AnzixBookmarkablePageRequestTargetUrlCodingStrategy(path, bookmarkablePageClass, null));

paranccsal tehetjük meg. Persze még lehet csinosíthatni, hogy a pozícióhoz rendelt paraméterek lekéréséhez frankó gettereket írunk valami leszármaztotott helyre, de ez innentől újgyakorlat.

Marad viszonta kérdés: Hogyan csináljam meg ugyanezt JSF-ben?

SCEA Beta

Sun Certified Enterprise Architect minősítés ingyen: itt
Ez egy Beta vizsga, azaz valószínű hosszabb lesz mint az igazi, viszont ingyen van, de teljes értékű certificate-et ad.

Jazoon fóliák

Kikerültek és előrhetőek innen.

A videók később lesznek elérhetőek a Parleys-ről (most még csak kettő van).

Vissza a gyalupadhoz

Holnaptól újra meló. Ma még csak eszmélkedés: az olvasatlan RSS bejegyzések számát már sikekerült 50 alá szorítani.

TODO list őszre:

* használhatóra hegeszteni az ANT alapú Build Systememet (project Merevaik)
* JCR + OSGi + Wicket (esetleg JSF) alapú egyszerű honlap motort kalapálni (akár saját build systemmel)
* a jum.hu domain regisztrációt elintézni, Confluence-t kidobni, és bármi mást helyette (akár PHP is szóba jöhet (Drupal), csak ne keljen vele egyelőre szarozni. Persze PHP is Quercus + Glassfish alatt menne).
* a JUM-ra angol leírást tenni, és regisztrálni Java User Groups-nak
* letenni a Sunos Web Service Certificate-t (véletlenül van egy ingyen voucher-em és el kell használni).
* fényezni az angol tudásom
* előadókat szerezni a JUM-ra. (pl. kereseni olyan embereket, akik OS java projekteken dolgoznak, és megkérni hogy beszéljenek róla. Ha tudtok ilyet, kommentbe jöhetnek.)
* DJL projectet kitalálni (egyelőre nem publikus, de a J betű Javát fog jelenteni).


ps: itt egy fasza Wicket vs. JSF bejegyzés. Csak azt nem értem miért nem kommentelhető :(

messze.net

Bár a posztok már megritkultak, de most a függőnyt is behúzzuk. Holnaptól augusztus végéig max 2 napot vagyok online, úgy hogy addig nem frissülünk.

Mine metsa. Menj erdőbe.

Java Content Repository Browser

A JCR egyik hibájának szokták felróni, hogy nincs hozzá jó admin eszköz (~pgAdmin, Toad). Kezdemények azért szerencsére már vannak. Ma kettő került az utamba: A JCR Controller és a JCR Browser.

Minkettő elég jó funkcionalitást biztosít, írni olvasni, exportálni importálni lehet mindent. A JCR Controller webstartról indítható standalone program (screenshot), de sajnos 1280x87.. ra optimalizálták. Ezt azt jelenti, hogy 1024x768-as felbontásban egyes mezők nem is láthatóak, nem érthetőek el. Ez azért eléggé lecsökkenti a használhatóságot. (Már aki szintén sajnálta a pénzt, monitorra).

A JCR Controller, szintén friss fejlesztés, egy war file-t kell deployolni, tehát webes, és belépéshez a repository JNDI címe és egy login név kell. A kedves dolog az benne, hogy mivel tudja ugyanazt a repositoryt használni, amit a webalkalmazásom, ezért nem kell JCR-RMI-t feltelepítenem, hogy megnézzem mi van épp a repositoryban. Még elég nyers (pl. idiot-sicher validálások sokszor hiányoznak), de működő és használható. Egyelőre ez marad.

BTW, kijött a JCR 2.0-ből a Public Review.

Széljegyzetek process killezéshez

Még a múlt hétvégéről maradt itt egy cetli, amin két dolog áll:

Egyrészt a Runtime.getInstance().addShutdownHook() Ami egy elindítatlan szállat ad a JVM-nek, hogy amikor meggyilkolja valaki a programunkat, a JVM becsukása előtt még lefutassa a szálunkat. (ctrl+c vagy kill esetén még lefut, de kill -9 esetén persze nem). Nagyon szép lehetőség fusizásra, és nyilván szép megoldásokra is.

A másik, hogy kill -3 parancsra a Sun (gyanítom, ez nincs specifikálva általánosan) JVM kiadja a futó java thread-ek stack trace-ét. Szegény ember JConsol-ja. Valamikor még hasznos lehet.

Java User Meetings II.

Ezzel a beszámolóval még adós vagyok:

Az első előadás az enyém volt, JBI-ról szólt. Egy kicsit lelkiismeret furdálásom volt utána. Miután végig fikáztam a TSSJS EU előadásait, aztán pedig észrevettem, hogy én is ugyanazt csinálom, ami máshol nem tetszett (pl. elcsúszok az idővel). Mindegy, azért remélem legalább néhány embernek hasznos volt.

A Dojo és Wicket előadásokról együtt: nekem mindkettő nagyon bejött. Jó fáradt voltam, de ébren tartottAK, mindkettő sok kódot mutatott, de nem tévedtünk el benne, de kaptam valami érzést, hogy milyen is belül kb. a felépítése a két dolognak. És átjött pl. hogy a javascriptnek igen is lehet szépsége az, amikor aspektus orientált dolgokat csinálunk kihasználva a kevsébé típusosságát, vagy hogy egy keretrendszer, ami nem akarja megváltani a világot, csak egyszerű és jól használható akar lenni, szépen megírva, az igen is perspektíva. (Tegnap este le is ültem Wicket-ezni, hogy kipróbáljam).

Szóval, ha voltak még az első alkalom után kétségeim, akkor most teljesen elszálltak. Jó arcok voltak, és jó értő kérdések. Számomra a megszerzett tapasztalat verte a sokszor szokásos marketinges-evangelizációs előadások információs tartalmát.

Száz

Kicsit több mint egy éve kezdtem el ezt a blogot írni, és most elértem a századik bejegyzést. Szeretnék most valami nagy és ünnepélyes dologt írni, de nem tudok igazán mit. Hétköznap van, egész éjjel hegesztettem az előadásomat, a meló meg megy tovább. Mindenesetre köszönök minden visszajelzést/látogatást/olvasást.

Vannak terveim a jövőre is, ennek az első jele, hogy a domain megváltozott (jtechnics.anzix.net alatt érhető el mostantól az oldal, meg persze a régi URL is működik). Ez (amellett hogy a mivel a problem szó kikerült a címből, a problémamentesség illúzóját adja nekem), egy régi terv első lépése, amikor is előbb utóbb át fogok állni egy saját JCR alapú blog motorra. (Tudom sok ingyenes is van, de én szeretnék JCR-es oldalt írni). Meg talán más dolgok is lesznek, de ezeket majd szeptemberben, ha visszajövök a szabadsáról.

Stay tunned, és köszönök mindent.

ui: Nem szeretem a bejegyzéseket, ahol nincs szó Javaról, úgy hogy itt egy link OSGi+Guice összeházasításáról. Bár ahogy én tudom service registry jelegű dolog az OSGi van, de talán nem elég injektálós. Nem tudom, de egyszer még utána kéne nézni, most nincs időm véigi bogarászni.

AntUnit

Az AntUnit egy viszonylag friss projekt (pl. nekem csak 1.7-es ANT-tal ment rendesen). Célja, hogy ha ant taskokat csinálunk, (vagy mindenféle antot kiterjesztő varázslatot) egyszerű legyen tesztelni. A dolog nagyon egyszerű:

<project xmlns:au="antlib:org.apache.ant.antunit">
  <!-- is called prior to the test -->
  <target name="setUp">
    <property name="foo" value="foo"/>

  </target>

  <!-- is called after the test, even if that caused an error -->
  <target name="tearDown">
    <delete file="${foo}" quiet="true"/>

  </target>

  <!-- the actual test case -->
  <target name="testTouchCreatesFile">
    <au:assertFileDoesntExist file="${foo}"/>
    <touch file="${foo}"/>

    <au:assertFileExists file="${foo}"/>
  </target>
</project>

Ha a fájlt egy egy másik ant xml fájlból au:antunit taskkal hívjuk meg, akkor a test kezdetű targatek fognak lefutni. (meg persze a setUp, tearDown), és az assertek nek igaznak kell lenniük. Ami miatt viszont nagyon jó a dolog, az az ért van, mert ha csak úgy minden flikkflakk nélkül lefuttatjuk az xml-t, akkor lefut hagyományos módon. Pont mint a javaban a (sose használt) assertionok: ha bekapcsolom beszól, ha nem nem.

Annál mindenesetre szebb, mint amilyen Junit-os hackeket csináltam eddig.

OSGi server-side

Még rég volt utoljára, amikor az OSGi-vel foglalkoztam, akkor még amikor a Server-side OSGi szóba került, a FAQ-k általában azt mondták, hogy ne kelljen nekem olyan, mert úgy is van OSGi webserver bundle, és na akarjam meglévő appszerveremet használni. Ami azért nem annyira szimpatikus hozzáálás.

Most a TSSJS EU-n láttam egy bemutatót, hogy az Equinoxra (az Eclipse alatt lévő OSGi implementációra) elkészült egy servletes bridge is.

A dolog nagyon egyszerű:

• Töltsd le innen a bridge.war-t.
• Deployold egy web containerbe.
• Indítsd el a webcontainer-t úgy, hogy a standard input megmaradjon (defaultból da kapod az OSGi konzolt). Tomcat-ben pl. a ./catalina.sh run a nyerő megoldás.

És megy is minden szépen. A console magáért beszél.
Ha deployolni akarsz bele OSGi dolgokat, arra is ott van a példa. Persze csak Eclipse-el fordítható (Ant?, Maven?), de utána a kapott jar-t már deployolhatjuk az OSGi konténerbe:

install file:///home/user/samplehttp.jar

Utána ss paranccsal látjuk, hogy megette-e, és start number paranccsal indíthatjuk is (a number az ss-sel kiírt sorszámot jelenti.) Még egy ss és látjuk, hogy a sample.http_1.0.0 Active. Nézzük is meg a http://localhost:8080/bridge/helloworld címet, és működnie kell a szervernek.

Ezek után, ha a JAR-t újra fordítjuk a konzolból újra tölthetjük anélkül, hogy a servletünk leállna, ami teljesen rendben van.

Belenézve a samplehttp forrásába két érdekes dolgot látunk. Egyrészt az Activator (ami betöltéskor hívódik meg) regsiztrálja a servletünket a context alá:

httpService.registerServlet("/helloworld", new HelloWorldServlet(), null, null);

Logikusnak hangzik, mivel innentől egy szerverünk van, ami alatt komponensek és a fő szervletnek a web.xml-éhez már nem nyúlhatunk, hogy a servlet mappinget piszkáljuk.

A másik, hogy az egész kódban sehol se hivatkoznak eclipse.org osztályra. Azaz az egész servletes regisztrálós dolog az OSGi szabvány része, valamint valószínű a szabvány további szolgáltatásai is (pl. Logging services) konkrét interfacek megadását is jelentik. (Ez még ellenőrizendő).

Mindenesetre pazar cucc az egész moduláris web alkalmazások írására, mivel a class loader nyűgöket rendesen kezeli az OSGi, és alapból neked csak annyit kel csinálni, hogy ésszerűen modulokba rendezn a kódot és szétcsapni részekre. És akkor persze majd lehet csinálni az extension pontokat, (erre is van benne támogatás, csak még nem láttam).

(BTW megalakult a JSR-316 néven a JAVAEE 6, ami újra felkavarta a JSR-277 vs. OSGi vitát, mivel egyértelműen leszögezte, hogy mivel a JAVAEE 7 JSR-277-re fog épülni, ezért szó sem lehet OSGi-ról. )

Summary: TheServerSide Java Symposium Barcelona 2007

Osszefoglalasul:

Nehez lehet jo konferenciat szervezni. A resztvevok egy resze egy csomo technologiaval ott talalkozik eloszor, nekik csak bevezeto eloadsokat lehet szervezni. Egy masik resze hardcore developer, ok hamar megunjak az altalanos bevezetoket. Talan savokat kine csinalni ilyen szempontbol is, beavato es boncolgato eloadasokbol.

A TheServerSide Java Symposium Eur szervezes korrekt volt, vegul is rutinosak a sracok, de nem volt benne az az agilitas, ami pl. a Jazoon oldalairol nagyon lejott (ok nagyon dolgoztak, hogy bloggereket bevonjanak, mindenfele ujjitast talaltak ki a programba, stb.). Itt alig volt olyan, ahol be akartak volna a resztvevokat vonni a buliba (volt egy tabla a folyoson olyan kerdesekkel, hogy pl. ORM-re alternativak, es oda lehetett firkalni, de nem nagyon haraptak ra az emberek).

Az eloadasok szinvonala eleg valtozo volt, de persze ez miattam is van, vannak nalam kevesbe fanyalgobbak is. Ugy tunik a rutinba eso szervezes dacara is a TSS nevnek volt annyi vonzereje, hogy eleg komoly embereket elhivjanak. Ennek ellenere nalam megis foleg kis emberek voltak akik bejottek.

A TOP5 eloadas nalam:

1. Jevgeni Kabanov: Aranea-rol
2. Stephene Colebourne: Java Closures
3. Ola Bini: JRuby
4. Alexander Popescu: JCR
5. Cliff Click: Java Performance Myths

A tobbi vagy kifejezetten rosz volt, vagy csak unalmas, csagy nekem nem mondott sok ujjat. A fent emlitett embereken kivul meg szimpatikus volt Burce Johnson a GWT fomuftija, o is eleg jo spielernek tunt. Ja es Neal Ford-ot is ertelmesnek tartom.

Osszessegeben en egy sesblog fele 0-7es skalan egy 4-essel ertekelem ay esemenyt. Ha lesz meg alkalmam elmenni konferenciara, biztos nem ide mennek ujra, hanem kiprobalnek valami mast, es csak akkor jonnek ide vissza, ha a tobbi sem bizonyul jobbnak.

DAY 3: TheServerSide Java Symposium Barcelona 2007

A harmadik napra elfogyott a lendulet, nagyon gyengere sikerult a felhozatal:

Meeraj Kunnumpurath, Jim Marion, Jeremez Boynes: SCA/Fabric 3 - Not the Same Olda Architecture Yet another Apache JCA implementation (lasd meg Tuscany). Harman tartjak. Az elejen bo lere eresztett bevezeto, de igen, tudjuk miert es mire jo az integracio. Aztan egy nem tul latvanyos demo. Valami olyasmit lattunk, hogy a Fabric3 clusterszeru kepesegekkel bir, de hogy mi az SCA tetje, es pl. egy PHP componenttel hogy tarsalgunk, az nem derult ki.

Ted Goddard: Ajax Security Smackdown Itt elkovettem azt a hibat, hogy beultem egy olyan ficko eloadasara, akinek a cege szponzor volt. Ti sohase tegyetek. Akinek van penze, az lehet, hogy okos embereket foglalkoztat, de nem feltetlenul jo eloadokat.

Jevgeni Kabanov: Step-by-Step Legacy Migration With Arena Ez a nap fenypontja, es talan a 3 nape is. Nagyon jo volt. Pont megfeleloen tomor bevezeto, a trivialis peldakat nem mutatja meg eloben, csak pont jo output kivagasokkal, de demo is van. Nagyon jo eloadas fejlesztoi szemmel. Jol felvazolta mi a tetje a dolognak, es hogy a kodban kb. milyen buktatok voltak, es kb. milyen megoldasrol van szo, hogy mukodik.
Maga a temara amugy csak jobb hijjan ultem be, de vann benne ertelem amugy is. Egy komponens alapu (naluk Widget) webframeworkot csinaltak (Aranea). Ez eddig meg mindenkivel megesik, nem nagyon izgalmas. De kitalaltak, hogy legacy alkalmazasokat ugy migralnak, hogy csinaltak olyan specko Widget komponenset, amibe pl. egy egesz Struts-os alkalmazast be lehet tenni. A regi alkalmazast reszekre bontottak, es a reszeket egyenkent tudjak atmigralni JSF, GWT, vagy akarmire (mihez Widget ragaszto osztaly kesz van, de ki fog jonni sok). A regi reszek a frameworkon belul Widgetek, es az uj reszek is. Azt hiszem nem tudtam jol elmondani, de erdemes vele foglalkozni, mert nemcsak hogy okos, de eleg lightweight megoldasnak is tunt.

Kirk Pepperdine: Mesauring up Performance Nyilvan tele volt a konferencia menedzserrel, de en hegesztomunnkas vagyok. Ha fel oraig csak folyik a mese, hogy igen merni kell, es nem tok mas rendszeren, mert akkor lehet, hogy nem jon ki a hiba, szoval ilyet hallgatva egy kicsit elszall az ihlet.

Thomas Watson: Server-side Equinox/OSGi and You Neztem az orat 1+1/4 oras eloadas, es 3/4 ora elteltevel meg csak Equinox-rol es Eclipsrol volt szo. Meg kicsit OSGi-rol, amit mar hallottunk tegnap. Szoval jo tema, lassu eloadas. Amugy arrol van szo, hogy vegre Servlet kontenerbe is behegeszttenek OSGi kontenereket. Kb 1,5 eve, amikor ez iranyba nezegettem valakik meg azt irtak, hogy ne kelljen nekem WAR fileban OSGI kontener, inkabb deplozoljak webszerver OSGi komponenst a standalone OSGi kontenerbe. Na ez azert eleg sovany, kb azt jelenti, hogy hasznalj Jettyt es kesz. Most vegre lathato, hogy megoldottak a dolgot, ami figyelemre melto. De ezt szebben is lehett volna mondani.

DAY 2: TheServerSide Java Symposium Barcelona 2007

Mielott teljesen elaludnek a gep elott egy gyors vazlat:

Cliff Click: Java Performance Myths: What Lurks Deep Inside a JVM? Az eloado a tipikus szaki, aki mar nem is tud a temajarol beszelni, mert csak azon morog, hogy micsoda szart latott megint. Nem egy karizmatikus figura, es sok slide arrol megy, hogy milyen hibakat latott mar publikalt C vs. Java microbenchmarkok olvasasakor. Azert nehany vicces dolog is kiderult:
Hogy melyik a gyorsabb, az sokban fugg az adott alkalmazastol +-10%-os peldat fel sorolt (egyet asm vs. bytecode szintjen elemezgetett is, hogy miert), de o kiotlott olyan specialis problemat is, ahol a Java 50%-ban gyorsabb volt (persze arra ment ra, hogy kibabraljon a gcc-vel). Elmentdta, hogy a final kulcsszo hasznalat tok mindegy, es hogy ugy lehet jo eredmenyt elerni, ho "common code"-t irunk. Magyarul olyat, amire van optimalizalo a JIT-ben :). Elmagyarazta, hogy a GC-tol nem kell felni (object poolingnak alapbol nincs ertelme, csak koltseges inicializalaskor: pl db conn). Sokat valtozott a GC-is ugyanis es 100Mb-os heapnel elenyeszo. A problema az 1-4G-s heapeknel jon elo. Ott tenyleg lesz. Alapvetoen nem volt szerintem kifejezetten jo eloadas, de most hogy irom a jegyzeteket, talan ebbol az eloadasbol tudtam meg ezen a napon a legtobbet. (Itt a blogja is).

Gregor Hohpe: Programming without a Call Stack - Event Driven Architecture A google izgaga eloadoja. Szerintem kb. 10 percben ossze lehetett volna foglalni a lenyeget, egy jo abra volt, az mindent elmagyarazott. Az EDA-t egyebken kb arra a szinte raknam, ahol az ESB-s orchestration vagy coreography van. Ez is egy tervezesi minta, ahogy a service-eket osszekapcsoljuk, csak mas a filozofiank az osszekapcsolas mogott.

Jonas Boner: Pojo Scalability and Large Workloads with Open Terracotta Vagy az ebed hianyzott, vagy az eloadas volt kicsit lankadt, de nem tudtam mindig kovetni, hogy mit miert ervel. Mutatott sok kodot, meg szep abrakat. A vegen osztott Terracotta bemutato cikket, ami kb. hasonlo szemben elmondta a lenyeget mint o, gondolom ez a cikk letoltheto a Terracottarol. Ebbe bele nezve azert kb. tudom pozicionalizalni. Megosztott JVM gepek kozott. Van egy szerver es annak jelentik le a kliensek az allapotot. A flikk-flakk kivulrol csak annyi, hogy deklaralni kll XML-ben, hogy mely osztalyok allapotat ossza meg a JVM-ek kozott (egy csomot felesleges alapbol). Meg persze nyilvan kod szinten belul dol el a dolog.

Az ebed alatt a Sun beszel. Glassfish, WS stack, sok ujdonsag nincs. Elmegy az ido, a vegen mar csak epp megvillogtatni van ido ket SunSpot-ot.

Adrian Coyler: OSGi - A New Foundation for Enterprise Applications A tag a Spring-OSGi vezetoje, igazablo errol beszel. Az OSGi-rol csak bo lere eresztett bevezeto (de azt nem tudom meg, hogy az alapveto versioninig-classhiding-en kivul mit tud az OSGi, pedig remlik, hogy vannak ott meg security meg mindengele kiegeszitok). Azt lattuk, hogy mi lesz belole a Spring 2.1-en. Hat jo. Szep munka.

Eric Lu: Getting Started with JSR-208 - JBI Azt nyujtja, amit vallal: Getting started. Ezt a reszt kibekkeltem. Ami miatt erdekes volt szamomra, hogy a szokasos Hello World peldat (Amihez NetBeans tutorial van, OpenESB-hez), o a sajat ChainBuilder cuccaval mutatja be. Varazsol egy Service Componentet (nem csak drotoz!), aztan Eclipse alapu vizualis huzigaloval beizzitja. Szolid eloado, de a termekuket (szinten OS) meg kene nezni.

Es innentol BOF sessionok kovetkeznek:

Bruce Johnson: Making GWT Better Annak ellenere bementem ra, hogy az elozo GWT-s eloadason nem voltam, es nincs tul sok GWT tapasztalatom. Az eloado nagyon meggyozo, ugyesen keverte a beszelgetest es a prezentalast, sok kerdes elhangzott. Jozan ember, teljesen jol latja a termekuk elonyeit, es a kompromisszumokat, amiket emiatt bevallaltak.

Attila Szegedi: Using the Java 6 Scripting API Hazankfia (sajnos nem tudtam vele beszelni, mert utana lecsapott ra valami oltonyos kerdezoskodo) szolid eloadast tart a Scripting API-rol. (Egyszer najdnem en is tartottam, ezert emiatt en mar atneztem az amugy eleg szimpla API-t). O persze azert mas kaliber, a Java 6-ban alapbol szamitott JS motort a Rhino-t tartja karban. Egy kicsit kevesbe ereztem rutinosnak, es ez sajnos kicsit ratelepedett az eloadasra, de a kerdeseknel mar sokkal felszabadultabb volt, es mondott meg ezt-azt.

Alexandru Popescu: JCR in the Real World A JCR-rol rovid bemutatas (kozepesen izgalmas). Aztan beszelgetesbe megy at, elmond ezt-azt InfoQ.com-rol, ami mogott JCR-van. Egy finn fickoval aztan parttalan vitaba bonyolodik a tarsasag, az absztrakciorol. Eleg szimpatikus ficko, es jo megerzesei vannak, es erdekesen mondta el. Habar azt nem mondta el, amit en tudok, hogy miert ultimate eszkot a JCR, de most nincs helyem mar ide irni a margora (hi, F.).

A nap folyaman nehany magyarral beszeltem, ok alapvetoen csalodottak voltak az eloadas szinvonalait illetoen. En kellemesen csalodtam azert, egy kicsit rosszabbat vartam, ha jo erzekkel helyezkedett az ember, kibekkelte a nagy hulysegeket, es akadt ertekelheto is jocskan.

Holnap utso nap.

DAY 1: TheServerSide Java Symposium Barcelona 2007

Akkor nezzuk:

Martin Fowler, Neal Ford: Language-oriented Programming and Language Workbanches Reggeli Keynote eloadas, azaz teljese tomeg elott prezentalnak, viszonylag altalanos dolgokat. Ennek ellenere meglepoen jo. Azon elmelkednek, hogy a programozasi nyelvek mennyire kovetik az eggyes problemakorok DSL (Domain Specific Language) leirasat. Pelda a Starbucks kavceg eloirasa volt, ahogy megmondjak hogy hogy csinalj lattet (szep angol mondat) es ennek a Java-s atfogalmazas volt, amiben persze egy csomo felesleges dolog is volt (a szintaktika miatt sok mindent ismetelni kellett, a lenyeg tekinteteben ez csak noise) Aztan beszeltek internal DSL es external nyelvekrol, az utobbi pl. az XML, mert kozelebb van a termeszetes nyelvhez, de igazabol azt majd leforditja maganak a Java.
A Ruby es mas dinamikus nyelvek eloretoreset is ha jol ertettem azzal magyaraztak, hogy a nyelv tomorebb, es termeszetesebb, az uzletemberek szamara is jol olvashat. Ami lehet, de szerintem a managereknek nem hiszem, hogy az lenne a bajuk, hogy a Java code-ot olvasni akarjak, es nem tudjak. (Lasd: specko Vision fejezet definicio: Vision az, amit a liftben el tudsz mondani a managernek.)

Stephen Colebourne: Java Closures: Kevesbe profetikus magavalragado stilus, de nagyon okosan osszeszedett. El mondja miert kell nekunk (lasd elozo temat, hogy egyszerubb kodot kapjunk, ami csak a lenyeget mondja meg). Es elemzi a closures proposalokat. Az egyiket o irta felig. Ha lessz idom leirom reszletesen a jhacksen, addig csak, hogy tudjatok kire kell szavazni:
CICE - nagyon primitiv syntax sugar proposal, az inner classokat egyszerusiti, sok mindent nem old meg. BGGA - nagy nevek adtak be (Az egyik G belole Gosling), a tobbi programnyelv alapjan alkottak meg. Ezert aztan minden franko dolgot tud, a szintakszisanak viszont semmi koze a Javahoz: rettentes (pl. az hordoz jelentest, hogy kirakod-e az utolso sorban a pontosvesszot a sor vegere). FCM - kisemberek irtak (az egyik az eloado), es engem meggyozott. Tudja azt amit a nagyoke, csak sokkal emberibb szintakszisa van, es sokkal magatol ertetodobb. A Sun allitolag egyelore kivar, megvarja a developerek mit mondanak. Szoval amig nincsen sajat tapasztalatom, addig en az FCM-re szavzok.

Erik Doernenburg: Taking Test-driven Development to the Next Level Erre eleg kivancsi voltam, hogy valami hiper test frameworkot mutat be, de nem. Kiderult ugyan is, hogy a prev. level a unit test mock objectek nelkul, a "next-level" meg mock objectumokkal (esetleg dinamikus mock keret rendszerekkel). Kicsit csalodtam. Lattunk sok kod peldat, es bebizonyosodott, hogy a decoupling jo dolog.
Tanulsag: ha nem hasznaltok mocks keretrendszert (pl. jMocks), akkor nezzetek utana mit tudnank.

Doug Clarke: Going to Extreme: kis markenting, az ebed tamogatoja, az Oracle reklamozza nekunk a termekeit. A kola melle elment, neha meg szep Eclipse+JPA demokat is lattunk.

SOA Industry Leaders Technology Panel. Ez egy kerekasztal beszelgetes, a nevekre nem emlekszem, es valtoztak is, ugy hogy nem is tudom kiirni. Amugy semmi ujjat nem tudtunk meg. JBI-rol azt mondtak, hogy persze egy megoldas Java-ban, adott esetben szukseg lehet ra, de mivel konkret esetekben kellhet, nem lesz o a fokolompos, csak egy a valasztekbol. A IONA-s ficko azt mondta, hogy az SCA es a JBI szerinte nem konkurensek, mert eltero szinteken vannak.

Ola Bini: JRuby - Ruby on the JVM. Nagyon magaval ragado eloadas, szamomora a nap egyik legjobbja. Bar eleg alapozo: Ruby alapok, miert jo a Java implementacio, a hibakra is jol felhivta a figyelmet, majd hogy milyen megoldasokat gondol ra. Nagyon gordulekeny stilus. (A ficko fanatikussagat jellemzi, hogy amikor megkerdeztek tole, hogy egy ilyen dinamikus nyelvet mennyire tamgatnak az IDE-k annyira mint a Java-t, o azt mondta, hogy hat, o Java-hoz is emacs-ot hasznal :) Na jo aztan komolyan is valaszolt (BTW az ot masik Core deeloper meg NetBeans-t)).
Nem vagyok meggyozve, hogy ez az udvozito nyelv, bar szep tomor, de en jobban szeretem a tipusasbb nyelveket. Azert mindesetre annzira meggyozo volt, hogy valamennyire meg kell neznem. Izgalmas lehet Java-ban nyelv interpretert irni.

Heinz Kabutz: Productive Coder: Onnan kezdtuk, hogy hasznaljuk billentyuzetet eger helyett, es aztan mindenfele code metrics fogalomfele huzott att. Fent tudta tartani az erdeklodest a kesei oran is. Ugyes pelda volt, hogy a semmit mondo getter javadoc-ra a Java SDK-bol hozott peldat, es megmutatta, hogy mennyire javult a helyzet a verziokban, es neha milyen buta komment van a Java forrasaban is (az idok soran sokat javult). Szoval nem volt rossz, csak valahogy az hianyzott, hogy miert nem emlitette meg a PMD-t vagyz a FindBugs-ot. Egy csomo dolog amit mondott tok igaz, de nekem az IDE-be agyazott PMD-m mar akkor ki irja, hogy az hulyeseg, amikor meg le se irtam.

ui1: amugy tobb embrre szamitottam. kb akkora az egesz, mint a magyarorszagi webkonf.

ui2: Csokoltatom a spanyolokat a billentyuzetert, meg a Guglit, aki feltetelezi, hogy ha eddig az osszes bejegyzest angol vagy magyar feluleten irom, csak azert mert az IE nyelve spanyol, azert megtanultam spanyolul.

TSSJS

Nyár van, mindenki nyaral. Újdonságok is alig, max, hogy elneveznek szép néven projekteket (pl. JAX-WS RI -> Metro), meg hasonlók. (Na jó a Java System Web Serverból kijött a stabil update, javaee5-ös servlet támogatással, ez mégis csak hír.)

Jövő héten megkezdődik két európai Java konferencia is a Jazoon és a TSS Java Symposium Europe. Jómagam a Hivatal jóvoltából az utóbin veszek részt jövő héten. Holnap reggel át is teszem a székhelyem Barcelonába, hogy szokjam a klímát. Mivel laptopom nincs (de már gyűjtöm a 100$-t), és a konferenciák elsősorban wifizett fotelekkel vannak felszerelve, nem internetkávézókkal, nem tudom mennyire tudok közben beszámolni, de utólag mindenképpen hírt adok az eseményekről.

DOM, SAX, StAX

XML-t parsolni rengeteg féle képpen lehet, a legismertebb módszerek mégis a fent említett apik. A DOM berántja az egész fájlt a merióba és viszonylag kényelmesen lehet utána kutakodni benne. A Sax egy sokkal kevésbé erőforrás igényesebb push parser: a feldolgozó megy végig az elemeken és közben a találta elemeknek megfelelő földolgozó függényeink (startElement, startDocument,...) szájába nyomja bele az adatokat. a StAX ezzel szemben remek pull parser. Szintén kevés erőforrsát eszik (nem tartja a memóriában az egész fájlt), és nem ő dirigál, hanem a programunk. Ha én azt mondom, hogy kérem a következő XML elemet, akkor megy tovább csak a parsolásban.

Hogy melyiket válasszuk, az a szokásos attól függ kérdés. Rövid segítség a döntésben pl. a java tutorialban.

Nálam a konkrét példa ez volt: viszonylag kicsi XML-ek zúdulnak rám eszméletlen sebességgel (JMS). Meg kell keresni mindegyikben két teget (kb. az első negyedben vannak) és az alapján kell megnézni, hogy akarok-e e velük kezdeni valamit. Amivel akarok, az kevesen van, azt már bárhogy feldolgozhatom.

Mivel gyorsnak kell lennni, egyértelmű hogy StAX vagy SAX. A StAX feldolgozását könnyen meg lehet szakítani (mivel én dirigálom, mikor jöjjön a feldolgozás bármikor abbahagyathatom), a SAX feldolgozásból legfeljebb exceptionnal lehet kijönni (ami azért nem egy szépségdíjas megoldás). Legyen tehát StAX. Illetve legyen mind3, és mérjem meg, hogy tényleg annyival gyorsabb-e a SAX/StAX mint a DOM, és hogy a konrét esetben a StAX/SAX sebesség mennyire vethető össze.

Nosza gyorsan összedobtam a kódokat, és rájuk eresztettem 3000 XML fájlt. Az eredmény: DOM ~ 100% sec, SAX ~ 80-90% sec, StAX 50 ~ sec. Érdekes, hogy a nagy szakadén nem a Stax/SAX vs. DOM között van, hanem a a StAX és az öszes többi között.

A történet szépsége az persze, hogy kiderült, hogy 3000 fájl feldolgozása is max 2-4 sec, és mivel adatbázisba is kell írni belőlük az adatokat, ezért valószínű tök mindegy mit használok, mert nem a parzolásnál fogok elvérezni. (Ráadásul háttér procesz, ahol 1-2 mp nem számít).

SCA vs. JBI

A JBI-t azzal szokás reklámozni, hogy bár SOA megvalósítás sok van, de milyen jó, hogy lesz nekünk egy szabványos, Java alapú. Úgy tűnik itt sincs azért kolbászból a kerítés.

A JBI 2.0 Review Ballot eredményi között (BTW csak ajánlani tudom a JCP szavazások commentjeit. Tiszta bulvár, jobb mint a Blikk) az IBM és a BEA az SCA-ra hivatkozva nemmel szavazott.

Azóta az SCA-ról próbálok guglizni, itt is egy cikk róla JDJ-ből. Kb. hasonló dologról van szó: hogyan kössünk össze komopnenseket egy SOA rendszerben, ráadásul itt különböző platformokat (Java, C++, stb.) is rögtön támogatnak. (Nem mintha WS-ekkel ezek nem lennének JBI-n keresztül összeköthetőek).

Ez a cikk (nem egy mai darab) arról beszél, hogy igazából a JBI meg az SCA nem zárják ki egymást, az egyik alacsony szintű implementációra, a másik általánosra szabvány, de én ezt még nem látom át. Mindenesetre a BEA és az IBM "No"-ja azt sugalja, mégis csak lehet némi átfedés a kettő között.

Házi feladat, kideríteni a két speckó közötti lényegi különbségeket.

Java előadások

A JBI-t továbbra is bogózgatom, mellé még érkezett kb. 800 oldal könyv is Java témában, de addig is link ajánló következik:

http://parleys.com

Igazából a BeJUG (Belgian Java Juser Groups) csinálja, és az előadásaiknak a fóliái/videói vannak fent igen használható formátumban. És mivel a BeJUG a Spring One és a JavaPolis rendezvényelben is benne van, azoknak az előadásaiba is bele nézhetünk. Jó anyagok vannak.

(Egyébként érdekes, hogy ahogy nézek más JUG formációkat, ott általában az az elv, hogy meghívnak külsős előadásokat (Sun, Oracle, stb.) és nagy előadásokat tartanak. Ehhez képest a mi megoldásunkban sok kissebb előadás van és a résztvevők adnak elő egymásnak. (Legalábbis az egy alkalommal így volt.) Érdekes az utóbbi megoldás is, hogy hívni valami Technology Evangelistet, de egyrészt szerintem egy ilyenhez még kevesen vagyunk, másrészt a fejlesztők előadásainak konkrét tapasztalatokról is olyan előnyei vannak, ami miatt szerintem mindenképp igény van rá. (Tacit knowledge-nek hívják, ahogy múltkor Kockától megtanultam))

JBI I.

Binding componentek és Service Componentek csücsülnek egy buszon, ahogy azt mindenki tudja (ha nem, akkor itt olvasható).

Amit még nem értek, hogy lesznek ezek példányosítva? Egy BPEL SC van, de akár több BPEL xml-t is deployolhatok, és akkor külön futnak. BC-kben, meg akár egy SMTP BC két külön konfigurációját használhatom. Szóval ez még nem tiszta, de nyomon vagyok.

Amúgy ServiceMix és OpenESB egyik se felel meg még tökéletesen nekem, de mindkettő ígéretes, és elég jó dokumentáció van mindkettő oldalán.

Ne menjen sehová, hamarosan újra jelentkezünk.

JavaOne fóliák

A PDF-ek már elérhetők. (A videókat jövő hétre ígérik.)

Sun fejlesztő konferencia

Na akkor lássuk:

Pat Pruchnickyj: A Sun Open Source stratégiája Alapvetően marketinges előadás, de nem vészes. Megtudtam pl. hogy az átlagos OS contributor 30 éves és 11 éves fejlesztői tapasztalata van. Ami tényleg izgalmas, mert ha körül nézek a projektemben, azért egy kezemen meg tudom számolni az ilyen tapasztalattal rendelkező fejlesztőket. Két dolog érdekelt volna még: az egyik (ezt lehet, hogy megkérdezem majd az előadót emailben), hogy létezik-e statisztika, hogy a megnyitott projektek hány százaléka külsős contributálás és mennyi továbbra is Sun munka. A másik a Sun bevételei. Valószínű egy nagy cég tulajdonosának kéne lenni, hogy lássam, hogy tényleg van üzleti model az OS-ben, és meg lehet élni supportból.

Nicolas Leszek: Sun partner programja fejlesztők részére: Ezt már igaz porszívó ügynök marketinges tartja. Elvileg a Sun partneri programról beszélt, de a Solarisra is nagyon rá akart beszélni. Azt hiszem ő azért volt itt, hogy ha véletlenül nem csak fejlesztők jöttek volna el a fejlesztői konferenciára, hanem vállalati vezetők is, akkor őket jól megekézze.

Vértes Miklós: Újdonságok a Java világából Ennek az előadásnak az egyetlen előnye az volt, hogy olyannyira gyenge volt, hogy az már szórakoztató. Az előadó elvileg a JavaOne-on bejelentett újdonságokról beszélt volna, szar viccek közepette, de még én is jobban képben voltam a JavaOne-on történtekről, pedig ott se voltam. Meg tudtam, hogy a JRuby azért jó, mert "raileken is fut" továbbá, hogy a JMaki és a Phobos "azt teszi, amire ki lett találva". ROTFL.

Alexis Moussine-Pouchkine: GlassFish, a Sun nyílt forráskódú alkalmazás szervere Ez egy ügyes összefoglaló GlassFish-ről, jól váltakoztatva a rövid gyakorlati bemutatókat a fóliákkal. Jól koncert a figyelemfelkeltő dolgokra (clusterezés, PHP futtatás Quercuson keresztül, HK2). Persze ezeket már nagyrészt kipróbáltam, sőt a hk2 forráskódjához is volt már szerencsém, de azért izgalmas.

Roman Strobl: NetBeans: nyílt forráskódú fejlesztőkörnyezet és ennél is több Az ő blogjának rendszeres olvasója vagyok, de előadni még nem láttam. Nagyon vidám fickó, és nagyon profi előadó (nem hiába evangelist). Két előadáson keresztül mutatta be a NetBeans 6.0 újdonságait, gyakorlati példákkal. Profi munka.

Simon Géza: Open ESB projekt A (saját magam által) vártnál sokkal tömörebb elméleti összefoglalót kaptunk, ESB, JBI, SOA szinten, ami nagyon jó volt. A demó gyakorlatilag abból állt, hogy megnyitottunk egy kész JBI-s alkalmazást és lefutattuk a tesztet. Én néztem volna részleteket is, mert éppen én is ezzel kísérletezek. Ami számomra új volt, hogy állítólag az OpenESB 2 már futni fog standalone is, és hogy a hármasra fog integrálódni a felvásárolt JCAPS-ból jövő mindenféle jó bele.

Zsemlye Tamás: Open SSO projekt Utolsó előadás, főleg elmlélet és termékismertető. Az OpenSSO-val már sokszor szemeztem, de az hiányzik hogy lássak egy ilyet élőben műköni. Sajnos Hello World itt sem volt, viszont nagyon meglepődtem, hogy mennyire pluginelhető kiterjeszthető az egész. Sokkal monolitikusabbnak látszott messziről. Még is csak meg kéne néztem.

A Glassfish előadásközben jutott eszembe a hasonlat, hogy egy kicsit olyan ez, mint a blogok és a nyomtatott média viszonya. Mivel naponta olvasva a híreket a neten, a hétvégi hetilapban lévő kis színes hírek már egy kicsit réginek tűnnek. Itt is azt volt, hogy a NetBeans és Glassfish demók és jóságok egy részét már rég olvastam a megfelelő forrásokból és láttam screencaston (sőt további jókat Jackpot, Schliemann). És mint a nyomtatott újságokat olvasva itt se az újdonság az amit ad az újság nekem (az már megvolt nekem RSS feedből), hanem az alaposság, ami révén olyan partikuláris dolgokat is megtudok, ami eddig elkerülte a figyelmemet, és amit miatt érdemes elolvasni az újság cikket. Ezért a néhány új dologért, no meg azért a 3 tényleg jó előadásért érdemes volt ott lenni.

OpenESB I.

Holnap Sun Tech Day Budapesten. Nosza gyorsan megint nekiálltam kísérletezni az OpenESB-vel, mert most majd lehet az illetékesektől kérdezni róla.

Tutorialokat már néha csináltam vele, de semmi komolyat. Most is valami egyszerűvel kezdtem, de sehogyan sem akart működni. A hibajelenség pont az volt, amit itt leírt valaki, csak én ellenőriztem, hogy a komponenesek meg vannak-e, meg a logot is felnyomtam finest-re, de semmi. Érdekes módon két különböző gépen is ugyanezt kaptam, és már nem is csak a saját programommal, hanem a a Sample-k közöl a SynchronousSampleApplication is ezt csinálta.

Nem baj, biztos valamit elkonfiguráltam az appszerverben valami múltkori játék folyamán, ezért letöltöttem újra és feltettem a teljesen friss NetBeans 5.5 + Glassfish párost. Újra megpróbálom a példát: most már megy szépen, de a Runtime > Servers fül alatt a JBI fában semmilyen komponens nem látható. (Valószínűleg az zavarta meg, hogy már volt fent egy Glassfish a gépen, és az újat is ugyanazon a "Sun Java System Application Server 9" néven rakta fel a Runtime > Servers alá. Igaz a régit kitöröltem utóbb, és nem javult).

Nosza bedühödtem és letöltöttema Java Application Platform SDK Update 3 Preview 2 hangzatos névre keresztelt cuccot. (Netbeans 6 M9 + OpenESB 2 + Glassfish 2). Felraktam, és láss csodát minden tökéletesen ment. Sőt még az SMTP binding komponenes is pöccre működött.

Tanulság: sose használjatok szar stabil dolgokat, ha kijött már valamilyen preview/beta.

JSF 2.0 Mit vennél bele?

Még a JavaOne-os hírek között volt, csak eddig nem sikerült írni róla. Tartottak egy rövid KickOff meetinget szerűséget a JSF 2.0 speckórol. Ed Burn rögzítette a 15 leggyakrabban hiányolt feature-t és mindegyikhez hozzárendelt egy becsült erőforrás összeget. A résztvevők alapján vásároltak egy fix keretösszegből, hogy nekik milyen feature kéne leginkább.

Sajnos nem tudom, hogy mennyi volt a keret összeg, de az én bevásárló listám valahogy így nézne ki:

• Mostly Get (80)
• Facelets (165)
• Skinks (60)
• Errors (80)

Csupán 385$, igazán szerény lista. További részletek itt.

Egyébiránt A JCP-t leginkább azért szokták kritizálni, hogy nem elég nyílt és átlátható. Ezt egyelőre minden projekt a maga módján és egyéni eszközökkel próbálja megoldani (Ahelyett, hogy a JCP.org végre elmenne egy kicsit communitysebb irányba) A JSF 2.0 specifikáció nyílt projektje itt található, de pl. a JSR-277-hez is bejelentettek egy nyílt, readonly levlistát a minap.

EP function

Lehet, hogy mindenki ismeri, de nekem új volt: a kérdés az, hogy hogy lehet EL-ben függvényt használni. És láss csodát, simán:

<c:when test="${f:isValid(param1,param2)}" >

Azért ez szépen néz ki. Persze a prefix az egy tld, amiben function teggel definiálható az isValid függvény. De inkább nézzétek meg a tutorialt, az teljesen egyértelmű. (scroll a végére).

Ti tényleg ismertétek?

NetBeans profiler

Azt még nem is írtam, hogy múltkor kb. egy napot ellötyögtem vele. Egy ANT alapú (freeform) külső tomcet-et használó NetBeans projecthez kellett belőnöm. Mielőtt neki kezdtem valaki fenyegetett is, hogy ő már próbálta és szétfagyott az egész.

Ehhez képest egész kellemesen csalódtam. Nagyon hamar működött, és tényleg kezelte az ANT alapú projektemet is.

Kissebb problémák voltak:

• Az IDE-ből indítva a tomcat-et profile módban úgy tűnt, mintha nem kapná meg a környezeti változók értékeit (ami pl. orakli eléréshez kell). Szerencsére volt lehetőség manual attach-ot is játszani, és azzal végül ment, csak command lineból kellett indítgatni az IDE-t.
• 1.4-est nem szereti nagyon (igaza van, én se szeretem), módosított JVM kell hozzá. Ez letölthet NB plugin formájában, csak a dependency rosszul van a pluginben definiálva, és ezért a legújabb profilerrel nem megy (persze nem volt túl nagy feladat a jarban megtalálni a descriptor-t és átírni a dependecyt, és utána már megy is.).

Ezt leszámítva tényleg szép színes szagos, és egész jól használható volt. Rögtön találtam is néhány furcsa dolgot (reflection api szokásos lassúsága) a projektben, ami miatt már megérte.

Rögvalóság

Két könyvre lenne szükségem, ami egyrészt jó lenne papíros formájában, a márészt meg elhatároztam, hogy becsületes leszek, és megvenném őket pénzért.

Az egyik a NetBeans RCP-ről most megjelent könyv, és a legjobb könyvnek tűnik a témában (konkrét RCP-re kihegyezett más ilyen könyvről nem is tudok). Valamint már a 6.0-t is figyelembe veszi, ami ősz előtt biztos nem jön ki, úgy hogy valamennyire biztos aktuális marad.

A másik egy régi alapmű, szerintem egy jó része már túlhaladott, de szintén egyetlen, amit ajánlanak SCDJWS témakörben.

Namármost mint mondtam papíroson kéne az egész, úgy hogy irány az amazon. Az amazonon 83$ ért hozná át nekem a tengeren. Ami némileg drága a hazak könyvárakhoz képest, dehát a tudásba be kell fektetni. A probléma csak az, hogy van esély rá, hogy itthon még ezt meg is vámolják és hozzá csapják az áfát, ami már jól megdobja.

Persze még mindig jobb, mint az amazon.de, ami csekély 100 euróért akarná kihozni (persze arra nem jön vám), ami már egy olyan combos 25 rugó környékén van

(A kiskapu-t is megkérdeztem, ők 28700-ért hoznák meg nekem a cuccost).

Persze, persze, tudom, hogy milyen a törpök élete, meg hogy ez kelet európa, de akkor is. Elkeserítő. És akkor még a magyar postán uralkodó állapotokról nem is beszéltem.

JUM 1.

Akkor lássuk:

Zsiga Péter: Java és SAP integráció Jco segítségével SAP elérése Javaban. Konkrét eset, de valahogy nem dobott fel. Nincs dolgom SAP-pal. Nincs is lehetőségem rá, ezért nem volt sok tétje számomra.

Hornyák László, én: Maven2 vs. Ant + Ivy Ezek mi voltunk. Kocka a Maven2 dependency maganementjéről szólt, tényleg csak röviden vázolva a lényegét (ő némileg kritikus magával szemben, én, aki használok néha Maven2-t azért elég jól értettem). Az én előadásomat kicsit kapkodósnak éreztem, talán kevesebről kellett volna beszélnem, és jobban elmagyarázni, hogy mi a tét. El is felejtettem ezt-azt mondani (JSR-277 kapcsolatok, Xavier Hanin az alkotó, stb.) Majd megnézem magam videón, és akkor még próbálok tanulni belőle.

Auth Gábor: ZK AJAX keretrendszer, AJAX JavaScript tudás nélkül. Számomra is a legkellemesebb meglepetés, tényleg jó előadás. Jól felkészült, és az előre legyártott screencasttal együtt jó ütembe tudta mondani az előadást, ami jó megoldás volt (pedig ugye én utálom a csilli villi bemutatásokat :-). Másrészt azért volt még nagyon szimpatikus, mert nem arról szólt, hogy a ZK milyen überdolog, és mindenki azt használja, hanem arról, hogy próbálkozott vele egy csomót (izzadtság), és talált egy csomó előnyt meg egy hátrányt. Kérdezte is valaki a végén, hogy akkor mire jó az egész, ha ennyi hibáját felsorolta? Pont ez volt a lényeg, hogy pontosabban megismertük a ZK-t és a korlátait is. A lehetőségeket sokszor el tudom olvasni a termék leírásában is, de hogy hol vannak a gyenge pontok, ahhoz tapasztalat kell.

Karóczkai Krisztián: Portlet konténerek AJAX csapdája Elég hosszúra nyúlt előadás. Én magam nem vagyok portlet hívő, ezért megint kevésbé hatott meg. Két dolgot tudtam meg. Hogy portlet konténerekkel általában nehéz Ajaxot használni (ez nem lepett meg), és hogy "egy erős hétvége" alatt meg lehet írni egy portlet konténert. Ez viszont nagyon meglepett, és nagyon izgalmas információ volt. Talán érdekeltek is volna ennek az implementálásnak a részletei, tapasztalati.

Czimmermann Gábor: Milyen hosszú az út az EJB2.0 és az EJB3.0 között? Vagy a késői időpont miatt, vagy mert az utolsó pillanatban készült az előadás, kevésbé volt pörgős. Meg persze én majdnem az egész speckót elolvastam a vizsga miatt, meg JPA-t is használok, úgy hogy kevéssé rázott meg. Az jó volt, hogy a JBoss-ról nagyon konkrét tapasztalatokat osztott meg (Elég döcögős az EJB3 támogatása, konkrét probléma injektálások), és ez indukált némi diskurzust is személyes tapasztaltokról.

Ami a szervezést illeti: Nagyon elhúzódott, akik siettek, azok el is mentek a szünetben. Szerintem kéne egy hoppmester alkalmanként, aki felvezeti a programot, és figyel az időre és figyelmeztet, ezáltal mindenképpen feszesebbre lehetne húzni. 4 előadás talán még szünet nélkül is lemenne, talán elég lenne annyi.

Persze itt két szemlélet van. Előttem egy meetup jellegű dolog (gyors esti program) lebeg, de Gábor pl. aki Pécsről jött fel csak ezért, (érthetően) nagyobb kaliberű dolgokban gondolkozik (már ahogy én látom).

Összességében (elfogult értékelés következik) nagyon ígéretes kezdetnek látom, és bár voltak olyan pillanatok, amik kevésbé kötöttek le, mindenképpen tanultam belőle.

Java One & JUM

Van ebben valami szépség. Miközben mindenki a nagy Java One-re készül, a Sun-osok gyorsan mindenből kiadnak egy milestone-t, és a aki számítónak érzi magát már mind elment San Franciscoba (regisztráció kb fél millától), szóval közben mi itt a magyar ugaron készülünk a hazai java-s előadásainkra. Kicsit kevesebb csillogás, kicsit kevesebb napfény, kicsit kevesebb résztvevő, de... (és ezt majd holnap este folytatom.)

De hogy valami hasznos nélkül ne zárjuk le ezt a bejegyzést se, ajánlom mindenkinek Xavier Hanin blogját. Ő az alkotója az Ivy-nek ennek folyamán van benne a JSR-277 (Java7-ben bemutatkozó modularity rendszer) EG-ben is, amiről néhány egész jó infó olvasható nála (bár egyébként elég ritkán frissít.)

Inglis

Előre bocsátom, hogy nagyon is tudatában vagyok, hogy mennyire ráférne az angolomra a fejlesztés. Habár angolul olvasok szakkönyveket és irodalmi könyveket egyaránt, és a Hivatalban is a mítingek (meg szinte minden) angolul folyik, angolul ugyanolyan szedett-vedett nyelvtannal fogalmazok néha, mint sokszor magyarul.

Hanem nézem az oldal statisztikáit, és látom, hogy sokan jönnek a gugliból egy konkrét kérdéssel, és valószínűleg elég lehervadnak, ha látják, hogy itt valaki magyaráz SSL-ről és Xfire-ről, de egyáltalán nem lehet érteni. Ilyenkor arra gondolok, hogy az lenne az illendő, hogy legalább a howto jellegű bejegyzéseket angolul kéne írnom, akár szar nyelvtannal is, ha eljutok valahová sok munkaóra árán, akkor legalább osszam meg az eredményt.

Hát nem tudom, talán nagyképűség. Régen is gondolkoztam ezen, és még nem jutottam semmi jó megoldásra, mert azért mégis csak a magyar nyelven érzem magam otthon, meg ebben a környezetben. Most mindenesetre lehet, hogy a JUM-ra készülő fóliáimat angolul fogom megírni. Úgy is magyarul fogunk beszélni, és legalább kevésbé lesz zavaró, ha néha ugyanazt magyarázom ami a fólián van. :-)

JVM bug

Néhány koléga mesélte múltkor, hogy az új cégükben van egy nagy régi legacy rendszer, aféle szent tehén. Kicsit rozsdás, kicsit döcög, de működik. Általában. Néha azonban elszáll, olyankor neki állnak hibát keresni. Mondják is a régieknek, hogy bugos a szent tehén. Nem, olyan nincs. Biztos a használt API a bugos. Megnézték, az jól működött. Akkor a JVM bugos. (Na persze, gondolták, majd pont az.) Azért elcsesztek vele egy napot, hogy bebizonyítsák, hogy a szent tehén betegeskedik és nem más. Persze ez többszőr is egymás után, és mindig ezzel az első reakcióval, hogy bugos a JVM.

Ez csak azért jutott eszembe, mert a minap előszőr találkoztam olyannal, hogy kaptam egy bug reportot, és végül kiderült, hogy nem én csesztem el valamit, hanem a JVM a hibás, és majd talán ki lesz javítva, addig meg van rá workaround, szépen leírva a bug adatbázisban, ami persze meg is oldotta a problémát.

No lám, ilyen is volt.

The Budapest New Technology Meetup

Tegnap előszőr voltam egy ilyen redezvényen. Tapasztalatok:

Az első előadás (Scrum a honlapon nem találom az előadót) tanúlsága az volt, hogy mennyire fel kell készülni egy 5 perces előadásra, és mennyire nehéz valamit összesedetten elmondani 5 percben.

Kelényi Attila (Kiskapu kiado) - Creative Commons - néhány jog fenntartva
Nekem nem mondott sok újat, de én azért ismertem is a témát. Már ebben a prezentációban feltűnt, hogy mennyire terjed az a stílus, amit én előszőr Dick Hardt-tól láttam a prezentáció készítésben (folyamatos beszéd, de a fólián nem vázlat pontok, hanem néha csak egy-egy hívószó). Az előadás kevésbé bolt gördülékeny, de jó volt.

Burgermeister Zsolt - Varga Koppány: Fordítássegítő alkalmazás.
Alapvetően egy új startup ötlete volt elmondva nagy vonalakban. A bevezető szavakkal már eltelt a fél idő. Nem rázott meg. Kívánom, hogy jöjjön be nekik, és térjünk vissza rá.

Vámosi Zsolt (3DBrigade) - 3D grafikai tartalom fejlesztes Next Generacios videojatek platformokon
Pöpec előadás 5 percre hegyezve, bár nem sokat tudtam meg belőle technikából, csak hogy komoly cég nyomja ezt itt Magyarországon. Érdekes képek, jó előadás.

Szalai Ferenc (NIIF) - Indentity 2.0 - a vágy titokzatos tárgya
Szóval én ismeret Dick Hardt alapművét, ahhoz képest nehéz újat alkotni. Kicsit el volt mismásolva a SAML vs. Open ID kérdés (ami persze nem is kifejezetten Identity 2.0-s elméleti téma, inkább már technika). (Az én véleményem kommentben itt).

Neltz Tamás (index.hu) - OpenID
Sok technikai részletet nem tudtam meg, de persze ezt már én ismertem. Az is vicces volt, hogy az előző előadás azt mondta, hogy azért OpenID és nem SAML, mert ez utóbbi nem támogatja jól a propertyk hordozását, bezzeg az OpenID. Ehhez képest ez az előadő azzal kezdte, hogy az OpenID is csak autorizációra való, nem property cserére. Különben jó volt. A privacy-t firtató kérdés is jól elgondolkoztatott. A whitelist/bacllist-re meg nem kaptam megnyugtató választ. (Mi lesz a SPAM-elő IdP-kkel).

Szóval tanulságos volt. Tanultam néhány dolgot, pl. hogy a Java User Meetings-nél is jó lesz az időt jelezni az előadónak, hogy ne fussunk ki az időből, meg határt szabni a kérdéseknek. Meg, hogy jó, hogy egy ilyen technológiailag elkötelezettebb témában nem 5, hanem 15 perc van, mert azért itt kelleni fog valamennyi idő felvezetni a méllyebb rétegeket

ANT, Maven, ilyesmi

Ami egy kicsit is megközelíti a Maven2 képességeit, is ANT-ra épül az az IVY. Jelenleg az Apache inkubátorában pihen, és egy remek jó dependency tool. Mivel ANT-ra épül nagyon jól be lehet passzintani mindenhová (pl. Netbeans, ami kezd jó ANT-ra épülni), ahová Maven2 plugin nincs is. Az API-ja is ígéretesnek tűnik, ki lehet cserélni jól a dependecy kezeléstől a latest verzió algoritmusig elég sok mindent. Ráadásul félig meddig kompatibilis a Maven-nel (pl. tudja olvasni az ibiblio-t).

Csakhogy ez idáig egy dependency management rendszer, és semmi több. A Maven2-t azért szeretik az emberek (vagy: ha szeretik, azért :) mert a definiált konvenciókkal sokkal egyszerűbb minden (erre múltkor volt egy frappáns angol kifejezés), azaz, ha mindig ugyanúgy buildelek, akkor érdemes ezt a részt csak egyszer megírni, és nem mindig implementálni ANT-ban.

Eddig oké. Természetesen ezt meg lehet csinálni IvY+ANT párossal is. Az ANT-nak elég jó API-ja van, az IVY szállítja a csomag és függőség kezelést. Csak azt kell elérni, hogy a letöltött csomagokban lévő osztályok integrálódjanak az ANT-ban (ezt nem lehetetlen), és azok rögtön beleszóljanak az api-ba. Így elérhetjük előszőr is, hogy a szokásos ANT taskok (pl. compile, jar, stb.) sehol se várjanak alapértelmezett paramétert, hanem mondjuk ahelyett valami magic propertyt használjanak. (Szimplán leszármaztatjuk az ANT taskokat), a magic propertyket meg előrde definiáljuk, ez lesz a konvenvió.

Sőt, azt is el lehet intézni, hogy alapértelmezett targetek legyenek (pl. compile, run, deploy), amik az ANT fájlban ugyan nincsenek benne, de meg lehet őket hívni a scriptből. (Feltéve, hogyha a csoda ivy+ant dolgunk a classpathban van). Meg mondjuk azt is megengedjük, hogy az alapértelmezett compile parancsot is felüldeifinálja a user, ha ő mindig más compile-t szeretne.

Ez szép, de akkor mi a kérdés? Hát az, hogy ilyen rendszer nincs. Jelenleg ugyanis Maven2 van, és mindenki (akinek van egy kis esze) azt használja. Amit felvázoltam arra lehetne egy Proof-of-Conceptet írni, de jelenleg nincs ilyen. Márpedig egy nemlétező program architektúrájáról előadást tartani meglehetősen öncélú dolog. Vagy fogom magam, és megírom az egészet, és tényleg komolyan veszem, és fegyverkezési versenybe kezdek a Maven2-vel (sok munkaórát beleölök), vagy hagyom az egészet. Ebben az esetben viszont elég felesleges előadást tartani egy olyan konkrét termékről (a konkrét termékről szól előadások már gyanúsak), ami nem is létezik, csak létezhetne, tehát a hallgatóság részéről gyakorlati haszna semmi nincs. (Kivéve egyetlen trükköt, hogy hogyan lehet automatikusan azzal definiálni ANT taskot, hogy egy jar-t bedobunk a classpath-ába). Sokkal inkább értelme van, egy létező dolog bemutatására konkrét tapasztalatokkal (vér, veríték).

Hát ezért bizonytalanodtam el, hogy érdemes-e megtartani a Maven2-es JUM előadás ANT-os párját. Mert ha az szólna valamiről nem az ANT-ról szólna, mert az egyértelműen nem ellenfele a Maven2-nek (Ezt egyébként a Maven oldal is igyekszik tisztázni, hogy ez nem csak egy másik build tool, hanem valami több annál). És amiről szólna, olyat meg úgy se fog használni senki.

Szerintetek?

JSF sources

Nem ecsetelem, hogy hogy jutottam ide, de jelenleg épp az egyik ablakban az Apache MyFaces forráskódja a másikban a JSF 1.2 Sun-os Reference Implementation forráskódja van. És ezeket böngészem csak úgy saját gyönyörűségre. Tanulságos. Lenyűgöző.

Ugyanarra a speckóra két elég eltérő implementáció, úgy hogy a specifikált részben a Java osztályok felépítése tök ugyanolyan, mégis teljesen különböző filozófiák, a működés meg persze ugyanaz (elvileg)

Megannyi sajátos megoldás. Például, hogy TLD fájlban definiálhatunk Listener-t is nem csak tag-eket. (MyFaces hibakezelése szerint lehet web container, ami nem tud róla) Vagy hogy a RI a WEB-INF/... os kérésekre nem forbiddent (403) hanem 404-et ad vissza. (A MyFaces kommentben csodálkozik, de követnie kell a RI-t, az a referencia). Vagy hogy a RI-ben ilyen frappáns metódus nevek is előfordulnak: verifyFactoriesAndInitDefaultRenderKit. 38 karakter ha jól számolom. Maga a gyönyörűség.

Szóval igen szórakoztató olvasmány, és talán a JSF megértéséhez is közelebb kerülök vele.

Olvassatok forráskódokat ti is, a legjobb olvasmány.

JAX-WS deploy

JAX-WS ugye meg van minenkinek? JAX-RPC utódja, és web service-eket lehet benne varázsolni könnyedén (POJO + Annitationok, ahogy ezt már mások is csinálták, csak most szabvány.) Éppen a 2.1-es van kijövőben.

Meg is írom benne szépen a service-t és deployolnám be, amikor kezdődnek a problémák. Glassfish szépen meg is eszi, de a Sun Java System Web Server (leírni is gyönyörűség ilyen frappáns rövid nevet :) nem. Hamar kiderül, hogy azért nem, mert a JSR-109-et, ami azt biztosítaná, hogy mindenféle plus deployment descriptorozás nélkül hipp-hopp működjön a WS, nem támogatja a Web Server. Persze trükközni lehet. Ez a kedves tutorial például (még a régi Web Serverhez tehát 2.4-es servlet konténert használ) elmondja, hogy milyen com.sun-os osztályokat kell servletként regisztrálni a web.xml-ben, hogy menjen a JAX-WS. Persze, a referencia implementációval. De ennyi erővel ne csináljunk szabványt, csak implementációt és dokumentációt.

A JAX-WS FAQ ezt így fogalmazza meg:
Q. Is the stand alone JAX-WS-based service developed and deployed on Servlet container is portable on all Java EE 5 based platforms ?

No.

Ennyi. Ott tartunk tehát, hogy JAVA 6 SE-ben lehet szabáványos hordozható WS szervert/klienset csinálni. JAVA EE 5-ben (ami tartalmazza a JSR-109-et) lehet szabványos hordozható WS-eket csinálni. Csak épp servlet containerek környékén (ami azért ezen a területen mégis csak a legvalószínübb) nincs rá hordozható megoldás.

Java contests

Nem magyarázom, nekem alapvetően bejönnek ezek. Ha több időm lenne valamelyiken biztos indulnék most is.

Ez a JavaOne-nal fog indulni. Valami jMakijMonkey enginnel kapcsolatban. Felírva az utánanézendők listájára. Érdektelen, csak JavaOne résztvevőknek. Benéztem.

Ez a Jazoon-hoz kapcsolódik, sciriptelés, és csak dikákoknak.

Itt meg az Atlassain kereskedelmi termékeihez lehet plugint írni, és licenszeket és TSS belépőket nyerni.

Hajrá.

Napfényes hétvégék emléke

(Énblog)

Telefonbeszélgetés után emailben kaptam néhány anyagot, ami távolról talán specifikációnak látszott. Meg volt köztük egy konferencia abstract is rengeteg bullshit-tel, meg egy megjegyzéssel, hogy igen, van működő prottípus szoftverük az algoritmushoz, és mennyire jó.

A beszélgetés us lefolyt, ekkor már nem egy hét, de 5 nap is alig volt a konrefenciára való indulásig, és kiderült, hogy az a szoftver, amit még senki sem látott, és nagyon gyorsan kéne. És aztán jött a rapid programozás. Nem mondom, hogy erre a kódra leszek a legbüszkébb, bár azért azt látom, hogy összehasonlíthatatlanul jobb ez a rapid kód is, mint mondjuk a néhány évvel ezelőtti. Hiába, csak tapasztal az ember, és egy Observer minta tényleg már csak izommunka. No meg a Hivatalban is megszoktam már, hogy mindent szépen dokumentálva és codestylolva, itt meg csak egyetlen szempont volt. Gyorsan egy működő demót.

Volt egy olyan rész, amit megírtak nekem előre C-ben, hogy az algoritmuson ne kelljen tökölődni. Copy-paste és kis kozmetika után ment is, majd néhány teszt után több helyen is elszállt. Kiderült, hogy a C-s ugyan működött, de kapásból két puffer túlcsordulás volt benne (nem túl lényeges helyeken), amire persze a Java rögtön dobta az IndexOutOfBondokat.

(Közbe regisztráltam a dev.java.net-re valami JUG szerű oldalt, remélem lassan approvolják is. Azzal is haladni kéne.)

Konferencia turizmus

Jön a a tavasz, majd a nyár is, végleg beindul a javás konferencia szezon. Jó lenne, ha valahová kiküldene a Hivatal. De mit is választanék - ha sikerülne rábeszélni őket - Európán belül. Első körben két potenciális jelölt van:

JAZOON Zürich, Június 24-28. 5 nap (igazából 3,5-4,5 Az első nap only tutorials, szerda csak délelőtt vannak előadások, du. városnézés).

Részvételi díj: (teljes/korai regisztráció 1245/995 (Student 460/370 vs. JUG tag 830/665) euró

Múlt: eltelt egy kis idő míg kiderült számomra, hogy ez az első konferenciájuk.

Tematika: minden Java, konferencia+kiállítás

Előadások: Összesssen 59 abstract, komplexebb kategóriákba sorolva (körülbelül ilyen megosztás: server side, desktop side, mobile és mindeféle más). A Spring jelenlét kicsi alul van reprezentálva, RCP általában Eclipse RCP-t jelen, és AOP, OSGi témakörökbenn is szívesen hallgatnék többet. Persze SOA manapság már kikerülhetetlen, itt is van, de nem annyira hangsúlyos (Igaz, ez nem server side konf). Sok olyan téma van, ami konkrét terméket és nem tehcnológiát jár körül. De azért van néhány érdekes téma, amire beülnék (pl. JAX-RS, Lucene)

THE SERVER SIDE SYMPOZIUM EUROPE Barcelona, Június 27-29. (3 nap)

Részvételi díj: 1516/1436 euró

Múlt: archívum nem, de 2006-os sajtóviszhang be van linkelve. Igazából ez az európai változat, a már lezajlott amerikai után.

Tematika: ServerSide, Konferencia

Előadások: Összessen: 36 abstract, van fent a honlapon, 4 kategóriában, ebből 16 az ARCHITECTURE sessions-ra esik, számomra igazából ez lenne érdekes, viszonylag erős is (pl. OSGi, AOP, ESB témakörök). A többi kategória nem túl említésre méltó. Néhány case study, semmi izgalom.

Összességében azt látom, hogy a konferenciák célközönsége nem elsősorban az a hard core hegesztőmunkás, aki én vagyok, talán inkább magasabb szinteket célozzák meg. Bér a Jazoon minden szinten nagyon nyomult (Student ticket) A TSSSE-nek a programja rövidebb, de erősebbnek tűnik, a Jazoon viszont sokkal agilisebb, nagyon kapaszkodik: ez az első alkalom, kedvezmények vannak, szervezői blog, próbálják bevonni a bloggereket, stb.

Egyszer valaki azt mondta nekem a JavaOne-ról, hogy minden képpen érdemes kimenni oda, ha a cégünk ki tud küldeni minket. Bár nagyon sok újat nem fogunk hallani (azt pedig a Java One esetében utólag meghallgatjuk a honlapon (profi megvalósítás, riszpekt)), de a Java iránti életérzés megtapasztalásához mindenképpen jó eljutni egyszer egy ilyen konferenciára.

Java Klub II.

Összefoglalás:

A kommentek alapján kitapintaható érdeklődést véltem felfedezni a dolog iránt. A következő lépés, hogy elmegyünk Húsvétra sonkát enni.

Aztán visszajövünnk, kiírunk 2-3 potenciális időpontot szavazásra (ötletek jöhetnek kommentbe). Összerakunk valami ingyenes helyen egy rövid oldalt (valami wiki-nek kéne lennie, már elkezdtem nézni), hogy mégse egy blogbejegyzésből kelljen informálódni.

A wiki oldalra ha valakinek jó témája van, azt oda be tudná írni. És el lehetne kezdeni gyűjteni az előadásokat. Kéne egy komolyabb becslés, hogy hány ember jönne el, és keresni kellene helyszínt.

Hát ilyenek jutnak eszembe. Bármilyen segítség, ötlet, megjegyzés jöhet kommentbe.

Klub

Mindenek előtt szeretnék két dolgot leszögezni.

Előszőr is ki nem állhatom az IRL találkozásokat, ha az egy netes ismeretség után következik. Mindennek megvan a maga helye. Ne keverjük.

És legalább ugyanennyire gyanús nekem mindenféle "macskatappancs testvériség". (Vonnegut). Ki fejezetten utálom azokat a társoságokat, amiket csak azért csinálnak mert összetartozunk. Nem tartozunk össze.

Amit viszont szeretnék:

Szeretnék egy olyan dolgot, ahol lehetne Java-ról beszélni, eszmét cserélni, előadást hallgatni, tanulni. Ami csak ezért lenne, erről szólna.

Hogy hogy képzelem el?

Leginkább valami klubnak. Aki részt akar venni, az csinál egy előadást. 
Nem hosszút, 15-20 perc plusz kérdések. Komolyabb mint egy blogbejegyzés, de kevesebb mint  egy konferencia előadás. 
Valami Javas témáról. Lehetőleg legyen minnél advancedebb (ne ott kezdjük, 
hogy mi a JSP vagy az EL) és ne szóljon olyanról, amit az ember egy az egyben elolvas a netről. Izzadságról szóljon, és tapasztalatról. (Ma tanultam erre egy szót: Tacit Knowledge).

Persze nem kell az adott témában teljesen pengének lenni, de ha van izzadság, akkor azért valamilyen szinten már válaszolni tudhat a felmerülő kérdésekre. Legyenek kérdések. És legyen kritika. Szerintem ebben az expozéban ez és ez volt jó, ez és ez volt rossz. Engem ez és ez érdekelne a témával kapcsolatban. Találkoztál a válasszal? Nem? Utánanézünk.

Az előadásokhoz kötelezően kéne tartoznia egy fóliának, és egy prototype alkalmazásnak ( javaalmanach szerű egyszerűségre törekedve), amit aztán szépen tolnánk fel a netre, és neten folytatni lehetne a diszkussziót a legutóbbi előadásról.

Azt hiszem kis hazánkban elég kevés a speciális Java konferencia vagy Workshop, ami hasonlót nyújtana. Múltkor néztem egy külföldit, és a regisztrációnál láttam, hogy JUG tagnak kedvezmény. Akkor kezdtem el nézegetni, hogy mi is egy JUG, és láttam, hogy azért léteznek máshol is hasonló dolgok, úgy hogy talán működhet is a dolog.

Ma reggel olvastam, hogy másoknak is vannak, ha nem is pont ilyen, de hasonló gondolataik. Lelkes lettem, ezért most e bejegyzés. Ha tényleg, néhány emberrel már bele lehetne vágni.

Mit gondoltok? Eljönnétek? Hallgatni? Előadni? Beszélgetni?

Web Konferencia 2007

((A twitter jól működött (technikailag) talán egyszer majd használom valami értelmesebbre is. Bár végig mobillal kellett vezérelni, mert wifi nem volt.))

Szóval egy rövid összefoglaló. 5 előadást láttam:

Simon Géza: Java Business Integration, azaz szolgáltatásalapú architektúra Java EE környezetben Jó összefoglalással kezdte a SOA-tól, hogy miért van erre szükség, és hogy miért pont web servicekkel oldja meg a JBI. Részletekbe nem mentünk bele, és személy szerint nekem sokkal inkább egy workshop hiányozna. De nem aludtam rajta. Tanultam két jó szakszót.

Szeredi Péter: A szemantikus világháló alapjai Ezzel a szemantikus világhálóval csak egy bajom van. Még nem lettam működő üzleti alkalmazást, amiben használták volna jól az ontológiákat, enélkül meg kicsit tét nélküli a dolog. Gondoltam legalább a kérdések között hallhatok ilyesmiről, de sajnos a kérdések helyét elnyomta a szétszéledés hangzavara. Maga az előadás kicsit egyetem jellegű, korrekt, de számomra kicsit lassú és unalmas volt. Nem tanulni akartam, hanem megismerni.

Molnár István: Java Persistence API, azaz szabványos Obejtum-Relációs mapping Java és Java EE környezetben Nagyon sok újra nem számítottam, nemrég az egész speckót el kellett olvasnom (SCBCD rulez). Azt gondoltam, hogy néhány alapozó mondat után, az alap OR mapping lehetőségeket mutatja be, hogy felkeltse az érdeklődést. Ehelyett egy számomra nagyon dinamikus és lehengerlő előadást hallottam, szinta ez összes lehetőséget (optimista lokkolás, öröklődés kezelése az adatbázisban, stb.) felvillantva. Emlékszem előtte egy kávét akartam inni, de utána már egész felvillanyozódtam.

Varga Péter: Webalkalmazás fejlesztés Java EE környezetben NetBeans segítségével: JSP 2.1, JavaServer Faces 1.2, AJAX Nagyelőadó, széles vászon. Az elején rögtönzött közvéleménykutatás, hogy ki mennyire ismeri a technológiákat: Java, Servlet, JSP, JSF. Kiderült, hogy eléggé az elejénél kell kezdeni, úgy hogy nagyon részletes JSF bemutatásra nem is kerülhetett sor. Persze elhangzott, hogy mire jó az egész, meg hogy hogy épül fel, de sok újat számomra nem mondott. Viszont VRG laza stílusban sziporkázott, úgyhogy végig élveztem az előadást.

Tóth Ádám: COMET webalkalmazás fejlesztés A végén úgy jöttem ki, hogy érdemes volt bemennem (ellentétben a szemantikus webbel), mert sok mindent megtudtam, de azért voltak az előadással fenntartásaim. Az elején volt egy fejezet, ahol sokat emlegette az architektúra szót, és mysql táblákat láttunk phpmyadmin-on keresztül, ez a rész talán felesleges volt, mert a későbbiekben nem volt sok szükség rá. Az is tipikus volt, hogy néha PHP kód került elő, hogy ezt így lehet megcsinálni, de nem nagyon merült fel, hogy ez csak egy példa és más nyelveken esetleg nem ob flush-sal kell csinálni, hanem csak az a lényeg, hogy a buffert kiírjuk. Ezt leszámítva a megvalósítások bemutatásai jól felépítve követték egymást, élvezhető volt.

Végül rövid eredményhirdetés hosszú sajnálkozással, hogy a Compo-ra milyen kevesen neveztek. Az egyik kategóriában csak egy induló volt, a másikban egy OpenLaszlos alkalmazás nyert.

Web konferencia Live

Mindjárt átgurulok a webkonferenciára. Meg próbálok közvetíteni, ilyet még úgy sem csináltam. (Ha le nem rohad a twitter, ahogy szokott).

http://twitter.com/karenin

Sun Java System Web Server

"Netbeans 5.5-öm még mindig nem támogatja a Tomcat 6-ot, márpedig kéne egy Glassfishnél kissebb memória igényűbb JAVAEE 5 Servlet container."

Így végződött az előző bejegyzésem, amire commentbe kaptam ötletként a Sun Java System Web Server-t. Első látásra rögtön nagyon szimpatikus volt. Régen próbáltam már egyszer, de akkor csak RHEL-re ment fel, most meg simán vett minden akadályt Ubuntu-n is.

Azt szokták mondani, hogy a SJSWS ugyanazt tudja mint az apache-httpd plusz még néhány mellé felhúzott modul/util együttvéve (pl. logrotate, webdav, reverse proxy). Van hozzá szép webes felület, command line-os tool, és persze xml-ből is konfigurálható. Viszi a legacy php alkalmazásokat, és deployolhatok bele java-t is. (A config felületeinek a kényelmességét jól mutatja, hogy létezik arra külön parancs, hogy selfsigned certificate-et gyártsunk a szerverhez. Apachhoz ehhez mindig rá kellett gugliznom egy howto-ra). A virtual hostokoat is nagyon korrektül kezeli (glassfish-ben pl. ahogy láttam a v2-ben lesz elég erős ez a funkció).

Szóval nagyon jónak tűnt, és a hétvégén úgyis újra húztunk a szerverünket, úgy hogy ez lett a web container. Részletes tapasztalatokkal majd kicsit később, valamennyi idő távlatból. Egyelőre nagyon jól muzsikál, bár vannak még megoldatlan részek (php-ből egyelőre csak a letölthető pluginjét sikerült beüzemelni, ubuntu-s defaultot nem, 80-as porthoz rootként futtatva az admin szervert is a config-deploy még nem működik, stb.). De egyelőre még a doksit se olvastam el, úgy hogy nem panaszkodunk. Jackrabbitot pl. nagyon könnyen sikerült beconfigurálni. (így).

Memória fogyasztást még nem néztem. A szerveren minden cakli-pakli foglal 200 megát (java még nincs nagyon deployolva, de legalább 15 virtual szerver fut), úgy hogy nincs pánik.

A dolgot egy kicsit rontja, hogy a fent idézett mondat nem oldódott meg. Ugyanis a SJSWS 7.0 update 1 Technology Preview, ami tudja a javee5-öt ugyan kezelhető a NetBeans pluginnel, de egyrészt a NetBeans nem hiszi el róla, hogy tudja, amit tud (csak 1.4-es projectet enged bele deployolni) másrészt virtual szervereket rohadtul nem kezel (mármint az NB plugin). Szóval itt még fényezhető lenne egy kicsit a dolog.

Cargo deploy?

A Cargo-val is úgy voltam eddig, hogy láttam, hogy van, és jó, és majd kipróbálom amikor szükgségem lesz rá. Most lenne, mert Netbeans 5.5-öm még mindig nem támogatja a Tomcat 6-ot, márpedig kéne egy Glassfishnél kissebb memória igényűbb JAVAEE 5 Servlet container.

Nosze hegesszük be a NetBeans-be. A NetBeans-ben az szeretem, hogy ANT az egész, ezért viszonylag jól bele lehet nyúlni a build processbe. Be is üzemeltem a cargot a doksi alapján, de sajnos csak azt sikerült elérnem, hogy elindítja az ANT task a tomcat-et, úgy, hogy beledeploy-olja a war-omat. De a lényeg az lenne, hogy a Tomcat fut, és alá hotdeply-al mindig frissíti az alkalmazást. De pont ez a HotDeploy, amit sehol sem találok:

Cargo offers a Deployer interface that container implementations can implement to perform hot deployments. At the moment, the following implementations exist:

* ResinDeployer
* JettyDeployer
* Jo1xDeployer


See the Deployer page for more information on how to perform a hot deployment. You can also deploy Deployables before the container is started using Static Deployment.

Nagyon úgy tűnik, hogy pont ezt nem tudja (ANTból legalább is), szóval közelről már kevésbé fényes a dolog.

Na mindegy, már húzom le a redőnyt, holnap meg megpróbálok egy context-et ráirányítani a build dir-re.

JCP WTF

Átalakult a JCP.org. Lehet pl. rá regisztrálni. Egyelőre amit értek, hogy a kedvenc JSR-eket ki lehet gyűjteni, és figyelni, de nagyon community-nek még nem tűnik az oldal.

Persze egyelőre csak a leírásból lehet tudni, mert kipróbálni nem lehet, mert szinte bárhová kattintok, elszáll, mint a...

    
System Error

There was an error processing your request. If you provided the URL, please check to ensure that it is correct or try to find what you're looking for using one of these methods:

    * Navigation menu on the left-hand side of the page
    * Search field in the header or left navigation menu

We are working on a new infrastructure, so please send us feedback at webmaster@jcp.org for the URLs you are certain are valid.

Thank you,
The jcp.org web team. 

Szóval szerintem ennél azért jobban oda kéne figyelni rá (kb. egy napja vettem észre, azóta nem javult), mert még a JSR-eket sem tudom letölteni.

jLibrary

A jLibrary egy Eclipse alapú kliensből és egy deployolható servlet/szerver alkalmazásból áll. A kliens tud működni standalone módba, vagy kapcsolódik a szerverhez, és JCR-be pakolgatja a dokumentumainkat, indexeli őket, attirbútumokat tárol, verziózik, stb.

A jó: Szép Eclipse-s felület, és mivel nehezen tudok ellenálni az új kütyüknek, rögtön ki is próbáltam. Mivel azonban mostanában olvastam, hogy Subversion-nal mennyire faszagányos verziozható webdav könyvtárat lehet csinálni, elgondolkoztam, hogy mit is ad nekem a cucc ennél többet. Indexelést, meta adatok kezelését. Éppen valami, de lehet, hogy eddig pont ez hiányzott a boldogságunkhoz.

Másrészt a funkciók nagyrészét a Jackrabbit adja. Ami nem baj (ügyes kis kliens attól még az egész stuff), csak jó olyan szemmel is nézni, hogy ez igazából egy JCP demó.

A rossz: Standalone módban ment is a dolog, de a war file-t istennek sem sikerült beüzemelni. Kicsit jobban ránézve a projektre tavaly év közepe óta nincs nagyon mozgolódás a témában.

Sun Web Developer Pack

Gondoltam, ezt meg kell nézni, annál is inkáb, mivel a leírások alapján nem egészen értettem, hogy mit is kapok: librarykat, netbeans plugineket, doksit?

Le is töltöttem (innnen), és rakom fel. Az egyetlen vicces az volt, hogy mondta, hogy kérek-e webcontainer integrációt. Persze kértem, mert olyanom még úgy se volt, és kajánul kiválasztottam a Tomcat 6-omat (igen, ot figyel alul a System Requirement-ben a Sunos app szerver mellett, és én már örültem is, mert a NetBeans 5.5 még mindig nem tud Tomcat 6-ot kezeleni), erre kaptam ezt a szép hibaüzenetet:


Na de azért felment: leginkább egy csomó library, melletük a forrás kódok és példák, tutorial. jMaki, phobos, bloggerapps, wadl, rest-api, ilyenek.

NetBeans plugin nincs benne, helyette fel ugrik egy ablak, ami tájékoztat, hogy használjam az Update Centert. Az Update Center valóban ajánl egy plugin suite-et (valójában csak a jmaki és phobos plugineket rakja fel.), és le is tölti nekem újra azokat a librarykat (illetve sajnos csak egy részüket), amit a SWDP-vel megkaptam. A NetBeans Samples projektjei alá se kerültek fel az SWDP-s minták, pedig az már csak egy lépés lenne.

Végül is a GlassFish integrációt kértem, de ez még nem derült ki számomra, hogy mit jelent (igaz még nem is nyálaztam át nagyon a doksit).

Na jó, de NetBeans és webcontainer integráció nélkül azért kaptam egy szép kupac dokuemntált sample-app ot, és librarykat szép rendben, amik közül sokat már tényleg meg akartam nézni, úgy hogy végül is köszönöm, a szünetre azért jó lesz.

tss link
arungupta bejelentész szerű