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ű

Checkstyle plugin

Bár a kódjaim most már kibírják a gyár checkstyle próbáját, néhány kimondatlan szabályoknak nem feleltek meg, és sajnos a checkstyleban nem is voltak hozzá rule-ok. (pl. a javadoc csillagainak a kívánt fajta behúzásának elenőrzése).

Úgy hogy múltkoriban összedobtam néhány Checkstyle extensiont saját használatra. Nem volt nagy flikk-flakk, mindenkinek csak ajánlani tudom, friss és használható doksi volt a honlapon, meg persze néhány példa is.

Antlr fát kapunk vissza, és egy mellékelt alkalmazással meg is lehet nézni a fát.
Ami viszont új volt, hogy se a javadoc-ot se a whitespace-eket nem parseolja. Az utóbbit úgy lehet kitalálni, hogy két token pozicióját megadja, és megnézzük, hogy köztük mi van a fájlban. Az előbbi is hasonló, de szerencsére erre már a Checkstyle is ad apit.

Ezeket kéne kipróbálni a Jackpotban is, és akkor tényleg nem lehetne már fogást találni rajtam.

Másnap

Rövid énblog:
Állítólag Charlie Parker (jazz, bebop, szaxofon) nyilatkozta az egyik lemezéről, amiven 240-es tempóban imporvizál végig, hogy ő azt azért szereti, mert ott nem kell gondolkozni, csak az izmok dolgoznak. Na, ma reggel valahogy én is így érzem, ahogy az IDE-ben rakosgatom odébb a biteket.

És akkor most két elem a reggeli RSS adagból:

Az első bejegyzés a Netbeans 6 Swing Application Framework bemutatásáról ajánl egy nyolc perces flashvideót. Bárki bármit is mondjon, szerintem a NetBeans varázslói elég jól el vannak találva: általában épp csak annyi kódot generálnak, ami még átlátható, és jó alap lehet belőlük bármihez. Szerintem még a hirhedt kéksoros Matisse is jól használható, ha az embert tudja, hogy hol nyuljon hozzá. Persze ritkán használom őket, de pl. a JSF megoldásait studírozva sokat tanultam. Ez a demó is elég szép, bár az ilyenekre mindig azt érzem, hogy szép szép, de majd akkor leszek meggyőzve, ha kezembe vehettem, és kipróbálhatom egy saját prototípusban. (Lassan már NB 6 betához se kell többet aludni egy hónapnál)
A videó külön szépsége, hogy megtanítja azt is az amerikai olvasóknak, hogy mi az a Trabant, és a végén J. Gossling egy zöld BMW-ben próbál versenyre kellni a trabanttal induló fejlesztővel. Drámai verseny.

És egy másik bejegyzés a szarkupacok milyenségéről, és a refaktoringról.

Summer Of (Java?) Code

És ebből vajon hány a java-s projekt?

Yadis

Amiről még nem beszéltem eddig. Tulajdonképpen arról van szó, hogy több URL alapú identity/egyéb szolgáltatás készítője észrevette a hasonlóságot a megoldásaikban. Mindenhol egy URL-t (vagy hasonlót) kellett beírni, és az URL-ről lehúzott dokumentumból (pl a META fejlécekből) megtudta, hogy hol van a tényleges URL, aki a service-t biztosítja.

Nosza egységesítették is a rendszereket. Az eredmény elég egyszerű (Részlet a speckóból):

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0”>
<XRD>
<Service priority="10">
<Type>http://openid.net/signon/1.0</Type>
<URI>http://www.myopenid.com/server</URI>
<openid:Delegate>http://smoker.myopenid.com/</openid:Delegate>
</Service>
<Service priority="50">
<Type>http://openid.net/signon/1.0</Type>
<URI>http://www.livejournal.com/openid/server.bml</URI>
<openid:Delegate>
http://www.livejournal.com/users/frank/
</openid:Delegate>
</Service>
<Service priority="20">
<Type>http://lid.netmesh.org/sso/2.0</Type>
</Service>
<Service>
<Type>http://lid.netmesh.org/sso/1.0</Type>
</Service>
</XRD>
</xrds:XRDS>

Látható, hogy egyszerűen adtak azonosítokat a service-eknek és azokat dobálja vissza, amiket támogat. A LID pl. speckó szerint támogatja az OpenID 2-t is, azaz a LID szerver mindig visszaad a Yadis leíróban egy olyan sort, ahol bevallja, melyik URL-n lehet OpenID-val támadni.

Magát a Yadis XML-t egyébként elég sokféleképpen lehet megszerezni az URL-ből. Lehet, hogy HTML HEAD sorban jön, lehet hogy META teg hivatkozik rá, vagy csak egyszerűen az URL-t meghívva rögtön kiömlik a szekrényből az egész Yadis XML.

Batik

Szeretem az olyan pillanatokat, amikor végre nem kell fanyalognom.

Kellett volna gyorsan rajzolnom egy SVG-t, a gugli kiköpte a Batik-ot. És tényleg. Lenyűgöz feature lista (An SVG DOM implementation, SVG microsyntax parsers, scripting module, a generator that creates an SVG document from Java2D calls, Swing SVG component, transcoder module), és minden megy pöccre, ahogy dokumentálva van, pont úgy.

Én pl. a Graphics2D-n keresztül írtam. Előszőr összelőttem a programot egy Swinges ablakon. (Egyszerűbb volt oda gyorsan összedobni. Aztán egyszer csak a programo szályába az SVG Graphics2D implementációját adtam, és oda ugyanúgy szépen írt mindent.

Apró örömök az életben.

OpenID java libraries

Kocka kérésére :)

Az OpenID.net három java libraryról tud.

IdPrism: Jelenleg én ezzel kísérleteztek, mert ez a legegyszerűbb. OpenID 1.1-et tud, azt viszint ajaxon keresztül is. A letöltött könyvtár tartalmaz egy példa servletet is, ahol mind az ajaxos mind a szerver oldali megoldásra látunk egy egyszerű példát. A kód nem egy nagy durranás, de legaláb könnyen át lehet látni.

OpenID4Java OpenID 2.0-sat is támogat, jól néz ki, ez lesz a következő, amit kipróbálok.

NetMesh InfoGrid LID Java. A legnagyobb baj vele, hogy ez alapvetően LID implementáció. Mivel a LID speckó része, hogy OpenID-ül is kell tudnia, ezért valahol benne van az OpenID támogatás.

LID meg egyelőre megfigyelés alatt. Annyit csak, hogy próbáljuk meg megkeresni az OpenID.net oldalon a letölthető speckót, és a rá vonatkozó licenset, és ugyanezt a LID oldalon. Na ugye. Tegnap írtam egy levelet a LID community levlistájára (az archívum nagyon gyér forgalmat mutatott, de hátha). Az első meglepetés, hogy a lista moderált (szóval ennyit a communityről). Aztán jóváhagyás helyett megkaptam emailben a speckókat, amik CC licensz alatt érhetőek el. De egyelőre maradok az OpenID 2.0-hoz való felzárkózásnál.

OpenID II.

Azt hiszem most egy kicst erről fogok szólni.

Ami még fontos:
Az OpenID elosztott rendszerű. Ha beütsz egy OpenID azonosítót (pl. karenin.myopenid.com) Azt a rendszer elképzeli url-nek. (http://karenin.myopenid.com/ és lekéri az az oldalt. Az oldal fejlécében lesz valami ilyami:

<link rel="openid.server" href="http://www.myopenid.com/server" />

Na erre a címre fog átugrani mindenféle request kérelemmel.

Ezt annyival meg lehet bolondítani, hogy egy delegate nevet is használok

<link rel="openid.server" href="http://www.myopenid.com/server">
<link rel="openid.delegate" href="http://karenin.myopenid.com/">

A fentieket beraktam jelen html fejlécébe. Ezek után már a problemjava.blogspot.com-ot is használhatom OpenId azonosítónak, ami használatkor a www.myopenid.com/server-en keresztül a karenin.myopenid.com-ot fogja autentikálni.

Azaz, ha később létrehozok egy másik OpenId-t egy másik szolgáltatónál, az OpenID-s honlapokat ugyanúgy használom tovább problemjava.blogpost.com névvel, csak a fejlécembe írom át a hivatkozást.

Ami még érdekes, hogy ha nem mondom meg (mondjuk egy reguláris kifejezéssel), hogy milyen OpenID szerver felhasználói jöhetnek be hozzám, akkor alapból mindenkit beengedek. Nem lenne nagy munka egy olyan OpenID szervert összerakni, aki kvázi egyszerhasználatos usereket generálna, és bármilyen requestre azt mondaná, igen ismerem, igen be van lépve. És indulhat is a comment spam.

OpenID I.

OpenID 1.1 nagy vonalaban:

A user regisztrál egy oldalon (pl. myopenid.com), és belép. Jó nagy session-t kap, be lesz lépve 2 hétig.

Az én oldalamon is be akar lépni. Itt beírja az OpenId azonosítóját. Ez alapján az oldalam átdobja redirect-tel a böngészőjét az OpenId oldalára. A requesthez hozzá csap némi információt, pl. hogy hova térjen vissza az autentikáció után.

Az OpenID oldal tudja, hogy a tag belépett (ott van az élő session, ha nincs, akkor belépteti), összerak egy HTTP válasz üzenetet arról, hogy ki ő, és hogy tényleg okés-e, és az előzőleg megadott oldara visszatér a megfelelő paraméterrel.

(Nem tudom világos-e. Azt hiszem valami frappáns hasonlat kéne a módszerre, de még nem jutott eszembe semmi.)

Akkor nézzük tovább. Tehát én átpattintottam a böngészőjét a felhasználónak az OpenID szerverre, és az nekem visszajött némi infóval, hogy okés a srác. Honnan tudom, hogy a visszajövő requestet tényleg a másik OpenID szerver küldte?

Erre két módszer van a speckóban:

A statefull megoldás, hogy előtte az OpenID szerverrel megbeszélek egy titkos kódot, amivel aláírja a választ. (A megbeszélésre a Diffie-Hellman algoritmust használjuk, ami lehetővé teszi, hogy nem biztonságos csatornán keresztül is megállapodjunk egy közös titkos kulcsban.)

A stateless megoldás, hogy miután a böngész visszatért hozzám, a servletemből a háttrében nyitok egy http lekérése, és én is megkérdezem az OpenId szervert: te figyelj, itt van ez a válasz, iyen paraméterei vannak, és ilyen aláírás van rajta, okés? Az OpenID szerver ellenőrzi az adatokat (ehhez már nem kel a felhasználó böngészőjétől függő session, hiszen csak azt nézi meg, hogy tényleg ő írta-e alá a dolgot, azaz, hogy az adott adatokra az ő titkos kulcsa is ilyen aláírást generálna-e. Ha a ugyanazt, akkor a user böngészője nem hazudott, és a requestben megadott OpenId userévvel garázdálkodhat nálam is.

folyt. köv., addig viszont egy kipróbálást ajánlok: regisztrtáljunk pl. a myopenid.com oldalon, kapni fogunk egy karanin.myopenid.com szerű azonosítót, és aztán próbáljunk meg belépni OpenID-sített honlapokon (pl. wikitravel.org). A MyOpenId azért is jó, mert autentikáció előtt mindig kér egy jóváhagyást, ezáltal jól látható a működés.

Proxy mögött

Tudom, hogy elenyésző azon esetek száma, amikor az éles szerver egy proxy mögül zizegne, de a development környezetben ez nagyon is előfordul.

Mert van olyan, amikor egy servlet nyit egy TCP connection-t, és azon próbálna kommunikálni valahová máshová (pl. OpenLaszlo, bizonyos OpenID implementációk). Na már most, ha ennek kommunikációnak a céges proxyn keresztül kéne hogy menjen, de ilyen lehetőségre a fejlesztők nem is gondoltak. (Na jó OpenLaszloban gondoltak, de ott nem izzúlt be.)

Valmi OpenVPN-s dolgot nagyon össze kéne már gyúrni.

servlet 2.5 / jsp 2.1 web container?

Sikeresen portoltam JSF 1.1-ről 1.2-re a picipuha-majd-elkészül alkalmazásomat. Persze a kérdés még mindig ott van, hogy mi fogja hajtani. JSF 1.2, azaz JSP 2.1 kéne.

Tomcatből a 6-os még mindig béta. 5.5 nem tujda. :(

Jetty-hez a fejlesztőeszköz (NetBeans) integráció nem megoldott (bár egy ilyen modult talán össze is dobnék), meg egy kicsit gyanús is, amikor azt írják, hogy 2.5-ös servlet container, de azért a dependency injection nem működik.

Glassfish az igen. Az nagyon szépen muzsikál, a Jackrabbit JCR-t is JCA-n keresztül simán vitte. Kár, hogy egy sima start 50-60 mega Heap-et eszik a Tomcat 5-6-jával szemben. (Jconsole) Ez azt jelenti, hogy a 200 megás szerveren elég necces lenne.

Tovább:
Kideríteni, hogy hogy lehet Glassfish szolgáltatásait szelektíven indítani (pl. ejb/JMS momentán még nem kell nekem.
Vajon ha a Grizzly-t teszem be jetty-be vagy tomcat 5.5-be (jettyhez már láttam nyomokat, hogy lehet), akkor servlet 2.5-öt kapok, vagy egész más szint?

java.text.Normalizer

Itt olvasom: azt hinné az ember, hogy ha UTF-8at használ, akkor már többet nem lesz semmi baj az ékezetekkel, pedig de: mivel az ékezetes karaktereket lehet több karakterből is összrakni az Unicode-ba, de sokszor van egy egy karakteres rövidítés is rá.

A cikk példája, hogy vilálog legyen:

String name1 = "Jos\u00E9";       // José with precomposed é
String name2 = "Jos\u0065\u0301"; // José with combining sequence e + ´

Aze a kettő ugyanúgy jelenik meg

A java.text.Normalizer mindig közös alakra hozza a Stringeket, így kereshetővé és összehasonlóvá teszi. Persze csak 1.6 alatt működik, és azért nekem van egy tippem, hogy mondjuk egy webes alkalmazásnál hány ember fog a beviteli formban composite uncide karaktereket használni.

Vagy lehet, hogy egy tisztességes DB kezelő az egészet lekezeli, és csak mondjuk file műveleteknél kell vele foglalkozni?

Vajon ékezetes domaineknél ez kettő külön domainnek számít? Nyilván ott is kell lennie valami normalizálásnak.

ANT custom selector

Nekem pl. új volt.

<fileset id="activefiles" dir="${workdir}">
<custom classname="net.anzix.ant.ucm.ActFilesSelector" classpath="dist/UCMReporter.jar"/>
</fileset>

Nem taskdef-et használunk, hanem custom selector-t. A fileset végig megy az összes fájlon, és a selectortól megkérdezi, hogy szerinte benne legyen-e a filesetben az a fájl:

public boolean isSelected(File basedir, String filename, File file) throws BuildException {

Nekem azért kellett, mert egy java osztályom visszaad egy file tömböt (ClearQuest-ben érintett fájlok, command line wrapperből szedve), és azt be akaromtam rakni egy filesetbe, úgy hogy később még exlude/includolni lehessen rajta az ANT-ban. Na erre pl. nem túl hatékony a módszer, de ameddig így is 3 mp alatt kijön az eredmény, egyelőre ez lesz.

régi szép napok

Van egy jar könyvtáram (illetve nem az enyém, csak szereztem), szép 1.5-ben megvalósítva (enum, generic, template). Van egy CDC-res szánt alkalmazásom, amit IBM J9-el akarok PocketPC-n futtatni (helyből -source 1.4).

Az egyik megoldásnak a retroweaver-t találtam, amit a lefordított class-okat machinálja át 1.4-es alatt is futathatóvá. Ant taskként működik, kipróbáltam, és működött. Szép. (Persze csak akkor , hogy ha nem használunk csak 1.5 api-jában lévő dolgokat).

A másik megoldás (és sajnos ez lett belőle), hogy kézzel nekiállok gyomlálni, és átírni a dolgokat. Sajnos ez lett belőle, mert kiderült, hogy a CDC/Basic Profile-bül hiányzik néhány awt.geom.*, amit a könyvtár használt, de kellett, úgy hogy úgy is át kellett alakítani.

Viszonylag kis api, de akkor is elég gépies volt visszaalakítani. Egy életre megtanultam, hogy mennyivel szebb 1.5-ben programozni. Sorban butítottam vissza mindent, az enumoktól kezdve az Autoboxingig, sok castolás a generic helyett. Brr...

custom EL

Az van, hogy Java Content Repository lesz a megoldás. A POJO-k (amit JPA-val tudnék pertisztálni)sajnos túl merevek, nem lehet őket kiterjeszteni könnyen, míg a JCR node-jait lehet, mert nincsenek hardcode-olva bele a property nevek és típusok (persze veszítünk a típusossággal, dehát volt már nagyobb veszteségünk is).

Persze a JSF-es Expression Language alapból nem jön rá, hogy a #{name.property}-re egy JCR-es node.getProprty().getString()-et kéne kiadnia.

Viszont lazán lehet definiálni PropertyResolvert:

1. A PorpertyResolvert- leszármaztatom
2. a konstruktor megkap paraméterben egy PropertyResolvert(a defaultot), és minden metódust neki delegálok tovább. Pl.

public Object getValue(Object base, Object property) throws EvaluationException, PropertyNotFoundException {

Ha a base JCR-es Node, akkor castolom és kiszedem a propertyt. Ha nem, delegálom vissza akonstruktorba megkapott resolvernek az ügyet.
3. a faces-configba kell még egy ilyen:

<application>
        <property-resolver>com.valami.OwnPropertyResolver</property-resolver>
</application>

Mindez JSF 1.1-ben, ahol külön value resolver is van. 1.2-ben még egyszerűbb/szebb a dolog.

SOA

(Épp valami zizi van a gépemmel, és addig köhögni sem merek, amíg bootcdről indulva le nem szinkronizál a home partíciom raid1-ben. Az után jöhet a hibakeresés.

A Knoppix bootcdn meg nincs java. Pedig kéne.)

Szóval addig sztori:

A múltkoriban meglátogattuk a gyárat, ahol a cég szoftvere élesben fut (régi c-s cucc, majd javaban újraírjuk.). Érdekes volt látni. Ülnek az operátorok, az egyik monitorban az egyik rendszer, a másik monitoron a másik rendszer, és még egy ablakban a harmadik. Átjárás korlátozottan. Azt hiszem kezdem érteni, miért lett most a SOA olyan nagy divatszó.

A legjobb viszont, hogy az egyik kopott konzolos alkalmazás még egy 286-oson futott. Arra fejlesztették, és azóta megy szépen, pont annyit tud, amit kell. Az egy kérdés, hogy ha elfüstöl benne valami honnan szereznek hozzá alkatrészt. De azt is megnézném, hogy hogyan integrálná a cuccot bárki is.

soros port II.

Na, azért csak meg kell védenem a Sun-t. Ugyanis az RxTx windowson ilyen zamatos hibaüzenettel szál el:

An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION

(Bár furcsa, mert az egyik eszközömmel simán megy, csak a másik akad ki. HyperTerminállal mind2ő szépen pörög.)

A régi Javacomm API val, meg azért megy minden rendben.

AZért felemelő ez, amikor a linux alá minden van, és Windows-os kompatibilitással kell bütykölni :-)

soros port

Soros portot szernék használni. Lehetőségek:

Java Communications API
Sun-os megoldás, (bár ha jól látom nincs rá JSR, ez csak egy megvalósítás). A 3-as változat csak linuxot és Solarist támogat, a 2-es változatot elvileg előbányászható, és abban van windows-os is.

RxTx
Mindent eszik: MaxOSX, Linux, Windows, BSD, stb. Nálam egyértelműen ez a nyerő.

CDC
PocketPC-re elvileg a CDC-be kell lennie.

Az SMSlib (soros porton SMS-eket olvasó API) pl. a sunossal és az rxtx-el is megy. Csupán ANT fordítás előtt ki kell cserléni egy class elején az import javax.comm-ot gnu.io.*-ra. Vicces megoldás.

SWT

Már megint le vagyok maradva a könyveléssel.

Még a hétvégén olvasgattam SWT könyveket, hogy lássam, mit is lehet csinálni vele. Eddig főleg NetBeans (ami ugye Swing) platform környékén jártam, és eddig sikerült elkerülnöm az Eclipse környékét, úgy hogy kicsit kiváncsi is voltam, meg aggódtam is, hogy el fog tartani, amíg egy nagy GUI-t bevágok.

Hát mit mondjak. Valahogy a PHP jutot eszembe. Nyilván a full extrás OOP absztrakciók felől nézve elég szerény a dolog, de az is igaz, hogy az egyszerűségnek is van esztétikája. Nem lehet véletlen, hogy annyi Eclipse plugin van: nyilván a GUI-t is egyszerűbb össze rakni.

Egyelőre nem tudom szeretni fogom-e, ahhoz még konkrét pocket pc-s projektek kellenének, de mindenesetre az SWT-s könyveket hamarább átfutottam, mint hittem.

PDA + Java II.

PDA fronton elértük az első sikereket:

Az AWT el lett doba, helyette SWT. Lejött egy default Eclipse telepítés Visual Editor modullal. (A folyosón azt mondták, hogy bármennyire is Swing pártiak legyünk, PDA-n még igaz (ami PC-n már nem igazán), hogy az SWT gyorsabban fut, úgy hogy mindenképpen használjuk azt).

Az SWT dll-t és jar-t felraktam a PDA-ra a J9 megfelelő könyvtáraiba, és vidáman futnak azóta az SWT-s programok. (A J9-nek van PC-n futtatható változata, oda a PC-s SWT kell, és akkor többé kevésbé a PC-n tesztelhető az alkalmazás.)

A legjobb leírás amit találtam ez, főleg, mert mellékel néhány példa forrást is.

Service Provider Interface

Eredetlieg azt hittem, hogy legalábis egy kiforrott API, de aztán kiderült, hogy maximum egy tervezési minta.

Arról van szó, hogy van egy alap programunk, és szeretnénk kiterjeszteni a funkcionalitást mindössze annyival, hogy bedobálunk a classpathba jar-okat. A(z egyik lehetséges) megoldás:

Van egy interface, ezzel definiáljuk, a kiterjesztési pontot. A bedobállandó jarokban implementáljuk az interface-t. (Eddig minden a szokásos).

Aztán csinálunk a jarokban egy könyvtárat és abban egy sima szöveges fájlt (mondjuk META-INF/services/com.domain.csodainterface) és egy-egy sorban felsoroljuk az implementáló osztályokat. A főprogram fogja a classLoader-ét és a getResources(META-INF/services/com.domain.csodainterface) metódussal szépen megkapja a fájl referenciákat. Ezekből kiolvassa a sorokat (amikben class nevek van) és ezeket reflection api-val szépen meghívogatja.

Azt hiszem ez csak egy módszer, de meglepően sokat találkozom mostanában vele (pl. Így lehet a radeox wiki engine-be új makrókat definiálni).

Linkek:
Ethan Nicolas vázolja a helyzetet
Jar speckóban emlegetve
Ez utóbbi emlegetés különösen kedves, mert nagy bizonyossággal hivatkozik egy Service.providers funkcióra, amit (ahogy számomra kiderült) nekem kell végül is megírni a fent említett módon.

PDA + Java I.

(Azt hiszem, kicsit lemaradásban vagyok, most csak a legutóbbi:)

Szeretnék Java programokat írni PDA-ra. A Sun-nak csak egy csomó speckója rá, de VM-je nincs. (A folyosón azt mondják, hogy volt, csak durván összeveszett az MS-sel, és azóta nincs.)

Az egyöntetű vélemény az, hogy J9-et kell használni (vagy ahogy ők mondják: WebSphere Everyplace Micro Environment). Ez elvileg 5$, de le lehet tölteni és ki lehet próbálni ingyen is. Fent is van.

Már csak a fejlesztő eszköz a kérdés. NetBeans-nek van CDC változatú Mobile Pack-je, de az se ilyen egyszerű. Ove Nordström (kimondani is gyönyörűség a nevet) bolgjából azt vélem kiolvasni, hogy két fajta GUI szabvány létezik az aGUI (Swinges, amit a NetBeans CDC tud és jsr, viszont Norström szerint még nem támogatják a készülékek) és az eSWT (az SWT egy részhalmaza és az IBM-ék nyomják). Ez utóbbit le is lehet tölteni és egy dll-el együt felcopyzni, és akkor menne. De ehhez nincs fejlesztő eszközöm.

A folyosón még azt mondták, hogy csináljak sima java projectet és csak az AWT elemeket használjam. Nem tudom ugyan használni a java.micro csomagokat (ami azért kelleni fog előbb utóbb), de menni fog.

Kipróbáltam és nem ment. Egyszerűen lefut a program, és semmit nem jelenít meg. Rejtély.

Tervek:
* hagyni a netbeans-et és keresni olyan Eclipse plugineket, amikkel megy a CDC és SWT csinál, és azt kipróbálni.
* Esetleg kipróbálni az IBM eclipse alapú csodáját (3 hónap trial, utána ~600$)
* törni a fejem, hogy egy awt miért nem indul el simán, és miért nem szól, hogy elszáll.
* keresni néhány mintát

gosling

Ez a gosling nem az a gosling. Ez egy ant átirat, amit az ant fájlokat használja, de nem xml-ben kell build fájlt csinálni, hanem Javaban. (Érdemes megnézni a példát.)

Egyrészt engem meg lehet győzni. Miért is ragaszkodunk mindig annyira az XML-hez, ha egyszer a kedvenc nyelvünk sokkal intelingensebb nála? A TSS-en épp a minap fanyalogtak az 1.7-es ant kiadásával kapcsolatban, hogy exception kezelés meg if/while elemek mennyire hiányoznak az ANT-ból.

Másrészt, engem mindenről meg lehet győzni, de mindenről csak akkor, ha együttműködik az IDE-mmel (most épp NetBeans). És lehetőleg ne egy ritkán fejlesztett pluginen keresztül, hanem pl. mint az IvY ANT fájlon keresztül teljesen legyen behegeszthető.

Amúgy már rég akarok írni, hogy azt hiszem az IvY lesz a menekülési útvonal a Maven2 elől. Van a fejemben egy lightweight ant+ivy based build környezet, ami azt hiszem pótolni fogja tudni. Csak kéne rá egy kis idő.

vision

Spring RCP-hez kerestem tutorialokat a minap, amikor ebbe akadtam bele. Nem csak azért tetszett, mert a Spring RCP közismerten alul dokumentált (viszont elég igéretes ahhoz, hogy ennek ellenére éremes legyen túrni) és egy jó tutorial nagy érték. Hanem mert ez nem is inkább tutorial, hanem inkább olvasó napló. Nem csak azt írja le, hogy hogynan kell életet lehelni a funkciókba, hanem azt is, hogy hogyan jutott el a megoldásra. Hol és hogyan találta meg a szükséges információkat.

Szimpatikus megoldás. Azt hiszem ezek után én is ezt fogom csinálni. Java olvasónapló. Mindennapi problémáim.

Ajax, Swing, ...

Múltkor az egyik állásinterjún amikor a vezető látta az AJAX szót rögtön az lett a feladat, hogy győzzem meg, hogy miért jó az AJAX, mi többet ad egy Swing alkalmazáshoz képest.

Mondtam neki, hogy rosszul fogja fel a dolgot, épp hogy kárpótol a Desktop alkalmazások feelingjének elvesztése miatt.

Csak arról jutott eszembe, hogy épp egy zseniális webappot csinálunk, illetve annak is most csak a css/js szkript részét. Annó desktop alkalmazás volt, de aztán kitalálták, hogy legyen webes alkalmazás, mert az olyan trendi. (intranetes, tehát kevesen használjk, és simán meg lehetne követelni egy WebStart-ot is a böngészőn kívül.) Meg is épült az első változat, jelenleg a másodikon kell dolgoznom. De ebbe most olyan szép követelmények vannak (itt legyen scroll bar, ott legyen, ezt mutassa, oda popup), hogy egy kicsit kezdek vágyakozni a Swing után. Az legalább egy Java api, és nem kéne itt gányolnom a CSS/JS-t. A böngészőkompatibilitásokról nem is beszélve.

Na megyek is vissza. Köszönöm, hogy elmondhattam.

jalopy

Kódformázó (éjlenek a céges policyk) aminek utsó release februárban jött ki (1.5rc) miközben a sourceforge-olt oldalról belinkelt cég már 1.7-et is árul. (Vajon a szerzőkre nem vonatkozik a GPL és nem kell kiadni a forráskódot?)

1. Előszőr is kiderült, hogy ha 2 sorba kerül a metódusnév, akkor nekem a kapcsos zárójelet a harmadik sorba kell írnom, és ezt semmiképp nem tudta. Sebaj, nyílt a forrás. Kinyitom, hunyorítok.

Interface-ek csak kevesen inkább közvetlen leszármazottak. (lásd Dependency Inversion Principle) már gyanús, hogy nem lehet szépen cserélgetni amit akarok. És valóban. Viszont a forrásban hamar megtaláltam amit nekem kellett és csak egy helyen írtam át. Nosza repacking és minden megy is szépen ANT taskból. (Elfogott a kísértés, hogy csak az újrafordított osztályt másoljam be a régi jarba, ha már tákolunk, csináljuk durván :-) Szegény ember IoC-ja mondja erre egy koléga.)

2. Persze vérszemet kaptam és kb 10 munkaórában össze is raktam egy NetBeans plugint rá. Ha majd letisztázom valahol publikálni is fogom, ha valakinek nagyon kell írjon a commentbe...

Amúgy már régen kísérleteztem NetBeans platformmal, de most valahogy minden összeállt és kezdtem átlátni a dolgokat. Nem OSGi persze, de azért elég szép komponens alapú, ami nekem alapból megdobogtatja a szívem.

1.6

Most már két tizedes választja el a jelenlegi project policyt a kurrens verziótól. Remélem nekik is fel tűnik. És legalább az 1.5ig eljutunk.

(A hírben mintha 60 napos ingyenes supportot írtak volna, amit ki kéne próbálni :-)

WTF

Egyébként a jsr 109-ből van. (És tényleg nincs 125 oldalnál több)

Utóirat

Kedves Jézuska. Szeretném, ha karácsonyra hoznál nekem egy rendes blogmotort, mert ebbe egy kínszenvedés volt beleírni az előző forráskódos cuccost. Átlátható architektúrája legyen (pl. Spring, JPA) és lehet pehelysúllyú, azt könnyebb bütykölni. Ja és egy ip-t is szeretnék, ahová 80-as portra rakhatom fel a glassfish-t, és nem kell közösködni minden mással httpd.apache-csal.

Mikrokernel és kampók

Az álmom továbbra is ugyanat. Egy j2ee-s (de legalább is web kontainerbe futó) mikrokerneles moduláris alkalmazást találni/írni. Néha, ha ez rámjön, akkor elkezdek guglizni, és olyanokról olvasok, mint a HiveMind, vagy az OSGi.

Az OSGi különösen szimpatikus, van benne dependency kezelés, modularitás, futás közben-i deploy. Az egyetlen, ami hiányzik ezekből a rendszerekből, az a hook rendszer, amire szintén ácsingózok.

Aztán belegondoltam és rájöttem, hogy ez teljesen érthető. Ha van lehetőség egy szolgáltatást (interface-t) publikálni, és azt más szolgáltatásokból meghívni, akkor a publish/subscribe minta szerint már vidáman lehet remek hook rendszereket képezni bármelyi felé.

Valahogy így képzelem:
1. van egy HookSystem.java, ahová regisztrálni lehet egy interface konkrét implementációit (akár többet is)
//publish service
public void create(Class interfacez);
//subscribe to service
public void register(Class interfacez,Object o);
//execute the hook
public Object getHook(Class interfacez);

Például:
HookSystem system = new HookSystem();
//publish
system.create(hookertest.Hook.class);
//suscribe
system.register(hookertest.Hook.class,new HookImpl1());
system.register(hookertest.Hook.class,new HookImpl2());
//get the executor
Hook hook = (Hook) system.getHook(hookertest.Hook.class);
hook.print("asdx");
Terménszetesen a két HookImpl* implementálja a Hook-ot.

2. és van egy parancs, ami meghívja az összes implementációt, aki regisztrálvan van. A vicc kedvéért ezt a HookSystem.getHook-on keresztül csinálnám, ami egy proxyt ad vissza a Hook interface-re, de bármit meghívva rajta az összes implementáló osztály végighívja a paraméterekkel (a visszatérési értékek kezelésén még gondolkozom, egyelőre legyen mindenki void, és a paraméterekbe irkálljon. Továbbá az is gyanús, hogy szép generic-kekkel még meg lehetne bolondítani az egészet.)

Hát így. Hook rendszerem van. Már csak valamelyik mikrokernel cuccost kéne átlátni.

Régi idők

Az egész utóbbi héten Struts-oltam. A régi Strus-cal. Mentségemre legyen szólva, hogy kényszerítettek, annak ellenére, hogy az önéletrajzomban felvételnél feltünően a Spring szerepelt a Struts helyett...

De nem is erről akartam beszélni, hanem hogy egy jó JSF-es alap tudással a Struts mennyire nem okozott meglepetést. Azt szokták mondani, hogy a JSF-et a Struts-on keresztül lehet eladni, mert az egyik specifikálója az a Craig McClanahan, aki a Strutsért is felelős.

Én azonban pont fordítva közelítettem, és ez se volt kevésbé izgalmas. Ismertem a JSF-et, és ez alapján a Strutsba nagyon könnyen el lehetett tájékozódni. Meg tippeltem, hogy minek hol kell lennie, és ott volt. Hiába, nagyon ugyanaz a kettő gondolkodása. Van bennük nagyon sok érdekes dolog, de azért az is érezhető, hogy mennyire távol áll az egész felfogás a Springtől. (Ellentétben a Spring-ből én személy szerint azt értem, hogy jó, hogy van egy elképzelésük az ideális felépítésről , de szinte mindent konkurencuát kipróbáltak, és mindennel össze passzintható.)

RSS reader & writer

Csak hogy ne mindig fanyalogjak: a ROME ügyes kis RSS/Atom olvasó/író. Igaz, hogy elég szimpla API (nem hasonlítható össze mondjuk egy complex webes security rendszerrel), de az nagyon szépen megcsinálva, és nagyon jól ledokumentálva. (pl. ilyen szép színes ábrák, meg persze elegendő példa). Szinte minden formátumot megesik, és lehet még plusz csatolmányokhoz is plugineket berhelni hozzá.

EBJ3 speckó anomália

Kedves esti olvasmányom (core változat innen).

Hanem valaki igazán megmondhatná, hogy hogyan kell ezt a két mondatot egymás mellett értemezni:

"Note that a container can also invoke the PreDestroy method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired. " (4.4 page 76 utsó bekezdés közepe-vége)

"The following scenarios result in the PreDestroy lifecycle callback interceptor method(s) not being called for an instance:

[...]

A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB container implementation-specific way." (4.4.3 page 81 alja - 82 teteje)

Most hogy nagyon töröm a fejem, esetleg arra gondolna, hogy method ready állapotból PreDestroy-jal timeout-tol, passive-ból meg anélkül? De azt azért ennél egyértelműbben is meg lehetne fogalmazni. Talán egy következő fejezetből kiderül. Ötlet?

XSLT vs. Java

Azt hiszem már írtam arról, hogy miért vagyok XSLT ellenes. Már már programnyelv bonyolultságú, de komolyabb dolgokhoz kevés benne a lehetőség. Nem is szólva, ha az egészet Java-ban írnánk meg, akkor mennyivel több funkciót használhatnánk átalakításkor (pl. adatbázis elérés).
(És akor nem beszéltünk a tesztelésről.)

Most olvasomtam itt: Simple Xalan excension function, hogy ez másnak is hiányzik: Xalan-ból kis namespace trükközéssel meg lehet hívni bármilyen Java függvényt. Persze innentől kezdve Xalan specifikus lesz az XSLT-nk.

Úgyhogy akkor én már inkább maradok a dom4-jnél, ahol egy az egyben lekódolták az XSLT algoritmusát Javaban, és egy egyszerű apin keresztül lehet XPath alapú rule-okat mondani. Jelentem használom és működik.

Glassfish + PHP + Drupal

Hogy miért? pl. legacy php-s alkalmazásunk is van, de szeretnénk melette ugyanazon a szerveren (és lehetőleg ugyanúgy 80-as porton) a java-s örömöket is futtatni.

A helyzet nem túl bonyolult még glassfish-ben sem, ahogyan ebben fórumban is írják. Le kell tölteni PHP/Java Bridge binárisát (war file). Kísérlet képpen deployolhatjuk is rögtön, és (nekem a JSF integráció kivételével) rögtön ment is minden demo szépen (session megosztás, php-ból java hívás, stb.).

Saját webalkalmazás sem volt bonyolultabb. Kísérletképpen, hogy egy echo "asd"; nél bonyolultabb alkalmazást vegyek a Drupal rendszert akartam látni működni.

1. Csináltam egy web alkalmazást
2. a JavaBridge.war-ból átmásoltam a web.xml-t (lényege, hogy a *.php-re a saját szervletét meppeli be).
3. a /WEB-INF/lib-ből a php-servlet.jar és a JavaBridge.jar-t hoztam át
4. feltelepítettem a php5-cgi csomagot (demo deployolásakor még nem volt fent! mivel a demo önmagában tartalmaz a WEB-INF/cgi-ben php binárist is)
5. bele a gyökérbe a php fájlokat
6. deploy, és minden szép

Persze még lehetne további dolgokkal kísérletezni. A szemem sarkából láttam, hogy elég komolyan lehet egymásba integrálni a kettőt (pl. az egyik demo java-s excell api-t használt php-ből.) Meg ki kéne valahogy mérni a sebességet is.

De kezdetnek elég lesz ez: könnyű sikerélmény.

Keep working

Ősz, levelek, netbeans (stabil), benne kísérletek. Ez van mostanában.

jBluez

A BlueZ a linux bluetooth stack-je, a JBluez egy JNI-s adapter hozzá. A SourceForge múzeumból egy 2002-es release tölthető le hozzá, ami megdöbbentő módon teljesen jól működik. Van hozzá 3 rövid példaprogram, megy egy rövid txt, hogy hogyan leheljünk bele életet, és egy mégrövidebb Troublehooting Guide, hogy hol fog elszálni. És tényleg elszállt ott, és tényleg úgy lehetett kijavítani, és utána tényleg ment. El voltam ájulva.

A szomorú az benne, hogy nem JSR-82 kompatibilist, de olyat még nem sikerült találnom Linux alá.

(Közbe frissíŧettem az ubuntu-mat, és ebben már libbluetooth2-van, és a bináris nem azzal ment. De egy szimbolikus linket megkockáztattam (új api a régi néven is), és megette.

OpenSSO

Gyűrés alatt. Vicces, mert mindenhol azt írják, hogy az OpenSSO based on Sun Java Access Manager, de én sose tudom, hogy hogyan van a reláció. Pl. az OpenSSO-ban csak maga a web-app van, meg most már az adapterek, de a plusz konzolos alkalmazásokat még nem találtam meg. A dokumentációja is érdekes: felrakták a Use Case leírásokat, meg az architektúra leírásokat, amit elég izgalmas olvasni, (milyen egy Sun-os ilyen), de a használatról nem sok. Csak admin és config guide-ok, semmi development útmutatás.

Van viszont elég sok cucc a docs.sun.com-on az Access Manager-hez, de az meg ugye nem pont ez. Amire hivatkozik sokszor hiányzik, és lehet keresni, hogy azok a utility-k itt hol vannak.

Tutorialt egyelőre nem találok, csak WebService titkolódzosat a NetBeans tutorialok között, de én egyelőre csak sima SSO-t szeretnék egy web appban. Illetve van egy , de még 8.1-es glassfish-hez, abból talán még lehet valamit.

A lényegből eddig ezt látom: egy deployolt webalkalmazás maga az Access Manager. Lehet más szerverekre Agent-eket deployolni, amik szintén webappok. Mivel ezek már a célalkalmazással egy domain-en futnak, ezért ha ezek kommunikálnak az Access Manager-rel, és után egy cookie-ba nyomják az eredményt, az elvileg a célalkalmazásból is hozzáférhető, és kezelhető.

Agent glassfishez csak 8.1-hezvan, de majdnem felment a 9-re, sőt valakinek állítólag ment is. A 8.1-eshez viszont demo is van, annak kéne mennie.

J2EE security

Bármennyire is csodálná valaki a j2ee építmény, azt mindenkinek be kell látnia, hogy a security rész elég halványra sikeredett.

Azt, hogy mit tud, és mit nem, elég jól összefoglalja ez a cikk, szépen körbejárja az 1.4-ben lévő dolgokat (a részletességre jellemző, hogy olyan fejezetek is vannak benne, hogy What is a container? De ennek ellenére tényleg korrket.)

A cikk a container security megoldásira ezeket az előnyökket mondja:

• beépített, tehát nem kell nekünk szarozni a session-ba rakosgatásával a User objektumoknak
• kőbe van vésve az apija (csinálhatunk pl. taglibrary-t a használatához, ami mindenhol menni fog)
• a több webapp között (egy szerveren) hordozni lehet a a belépési információt
• Átmegy a webtier és a business tier között

Nekem ebből az utolsó a legmeghatározóbb. Az azért tényleg kényelmes, hogy weben authentikálok, és EJB-k között is meg lesz a user info. Viszont cserébe a container semmit sem ad. Nem lehet jól bővíteni, az apija minimális, auditálás 0, stb.

Van ugyan a JAAS, de ahogy a cikk is írja:

JAAS is included as a required authentication method that containers must support. But the specification is not strict about how the container should provide this functionality; therefore, each container provides different support for JAAS.

Pl. a Sun Java Application Server-ben egy com.sun-os osztályt kell leszármaztatni saját realm írásakor, ami ugyan leszármazottja a JAAS osztályoknak, de egy másik appserveren hajunkra kenhetjük az egészet.

Az meg már csak hab a tortán, hogy a JAVAEE 5 speckóban ilyen kedves bekezdések vannak:

Web-based internet applications often need to manage a set of customers
dynamically, allowing users to register themselves as new customers. This scenario
was widely discussed in the servlet expert group (JSR-53) but we were unable to
achieve consensus on the appropriate solution. We had to abandon this work for
J2EE 1.3, and were not able to address it for J2EE 1.4, but hope to pursue it further
in a future release.

(kiemelés tőlem)

Nem marad más hátra, mint mindenféle külső szoftvert használni. Ezek közül is 2 megoldást találtam:

• Gyártófüggetlent, ami csak a servlet apira épül, jól hordozható, és általában elég pehelysúllyú.
• Robosztus megoldásokat, amiktől gyártófüggő lesz a kódunk, viszont SAML-tól kezdve mindent tud.

Azt utóbbira (amennyire látom) példa a Sun (Java System) Access Manager termék, ezt még nem sikerült mozgás közben látni, az előbbire viszont egy elég jó (bár nem túl friss lista) olvasható itt.

Amiket ebből megnéztem

jGuard: Ez nézett ki a legjobban, valamennyi doksija is úgy tűnt, hogy van, van nem túl régi release, és a tervezése is elfogadhatónak tűnt távolról nézve. Gyakorlatban viszont se Tomcat-tel se Glassfish-sel nem sikerült működésre bírni a doksija alapján. 3-4 óra szívás után frissen telepített Tomcat-tel (NetBeans embedded-del nem) a példa alkalmazást sikerült feléleszteni.
Amúgy Pure JAAS modulokat eszik, valószínű, ha egy kicsit szájbarágósabb, precízebb leírása lenne, még tetszene is.

Kasai: Ezt még több helyen linkelték: 2005-ös release. Azt mondja, hogy az ő saját API-ja sokkal jobb mint a JAAS. Hát lehet.

Seraph: Atlassian, tehát már ajánló levél, plusz tisztességesen legenerált lap/doksi (maven). A SSO menüpont alatt viszont azt ajánlják , hogy úgy használjuk SSO-nak, hogy egy szerveren autentikálunk, ott egy cookie-t ragasztunk a kliensre a user névvel. És ha a domain alatt egy másik alkalmazáshoz téved a felhasználó, automatikusan beléptetjük a cookie-ben tárolt felhasználó nevére. Ezt vagy nagyon nem értem, vagy nagyon gyanús. A cookie-k mintha kliens oldalon lennének, és azt a user nevet írom bele, amelyiket akarom.

Gabriel: Azt mondja azt adja mint az EJB (ami nem túl sok) csak EJB nélkül. Mellesleg halott

Mindig óvva intenek, hogy feltaláljam azt, ami már úgyis meg van, de egyelőre úgy tűnik, hogy ha normális security szolgáltatásra lesz szükségem nekem kell majd implementálni.

DOM4j vs JDOM

Vicces dolog két olyan library összehasonlítani, amiből az egyik utoljára 2004/09/09-ben a másik 2005/05/16 jött ki, és azóta semmi. Mindenesetre a JDOM és a dom4j is olyan dolgokra jött lérte, amire elvileg sem a DOM sem a SAX nem képes.

Mindkettő tud írni és olvasni SAX-ból és DOM-ból. a JDOM azzal reklámozza magát, hogy sokkal egyszerűbb, mert milyen jó dolog olyanokat írni, hogy

Element e = new Element();

A dom4j ezzel szemben viszont sokkal jobb :-)
Jó elismerem, kell hozzá factory, hogy létrehozzunk egy új element-et (illetve ez sem biztos, mert csak a gyökér elemhez kell, utána lehet az element.addElement("gyerekteg") -gel is létrehozni új gyerek elemet, ami visszaadja az új elementet.

Viszont cserébe minden csak interface. Alatta a beállításoknak megfelelően különböző implementácíójú osztályok lehetnek. Van pl. olyan, ami egy kicsit több memóriát eszik, de sokkal gyorsabban keres attributumokra, van olyan, ami olyan dom4j komponens fát csinál, ami simán castolható DOM fává (nem kell egy új DOM fát építeni a konvertálásnál), és ez azért elég szép dolog.

Van benne még mindenféle adapter Swing-es elemekhet (pl. TableModel), tud XSLT-jellegű transzformációt (Rule-oknak hívja magát), amit két bejegyzéssel ezelőtt szerettem volna. A gyerekeket meg tudja mondani List-ben, Iterátorban, vagy egyenként (for ciklus). Szépen kezeli az XPath-t, keveset fogyaszt, és a dokumentációja is egy újnyival több mind a JDOM-nak.

Maven2

Mit akarok csinalni egy projekttel?

• Létrehozni
• Librarykat hozzáadni
• Megírni a kódot
  
• Buildelni
• Tesztelni
• Futtatni
• Csomagolni
• Publikálni

Akkor nézzük mit ad nekem ehhez Maven, es mit a hagyományos IDE alapú fejlesztés (nálam NetBeans)

Létrehozás: Mivel csak standalone Java programot csináltam nem volt szükseg bonyolult archetypokra. Netbeans kreálta alap pont olyan jó volt mint a Maven-es.

Libraryk: Az nagyon okos, hogy a Maven egy helyen tárolja a függősegeket (azaz csak egy helyen kell meglennie pl. a log4j.jar-nak), de ugyanezt az IDE-k is tudjak. Igaz, itt fontos, hogy az összes hasznalt gepen ugyanolyan nevű shortcutokra legyen beallitva a jar file. Ha több gépen is fejlesztjük az egy projektet nagyon hasznos lehet, hogy a Maven library hivatkozás globalis, tehat ha beirjuk mi a függőség, bárhol is vagyunk letölti neküknk uazt a jart.

Megírni a kódot:Sajnos ezt is kell, és hiába csinál egy csomó mindent meg helyettem a Maven, ha a programozást segítő kiegészít funkciók közben meghallnak az IDE-ben, akkor nem fog érdekelni a dolog.

Buildelni/tesztelni: Ez mindkettőben ugyanaz az élmény. Bár Buildelni Netbeansben csak a saját ant build szkriptje alapjan sokkal gyorsabb, mint meven ide-n keresztul.

Futtatni: Ezt Mavenben vagy úgy eldugták, hogy nem találtam, vagy nincs. Ideből röhögve.

Csomagolni: Netbeans alapból jar csomagot állít elő, a dist könyvtárba. Maven plugin némi szöszölés után sokkal jobban testreszaható. Bár azt hiszem ant alapon a NetBeans-et is meg lehetne tanítani okosabb dolgokra.

Publikálás: Ebben egyértelműen a Maven a nyerő, site-ot csinál, reportokat generál.

Szóval itt tartok. Próbáltam a mevenide-t NetBeans-hez, nagyon szép, csak pont a finisben hasal el. Pl. ha Maven projektet nyitok nem használhatom a persistence-s varázslókat. EJB3-mal meg se mertem próbálni. Ha csak command line-ból használok Maven-t, és fejlesztéshez NetBeans-t akkor is iszonyú szívás a dolog.

A Maven a library kezelésben nagyon erős, meg a site deployban, de emellett hiába van róla ingyenes könyv, meg a honlapon elég sok guide nagyon nehéz eligazodni a doksikban, és advanced dolgok már nincsenek nagyon leírva. A library kezelést lehet mással is helyettesíteni (pl. Ivy), de a report generálás azért hiányozni fog.

XSLT logika javaban

Ezzel ax XSLT-ve en sohasem voltam kibekulve. Szep az elmelet, de ha bonyolult dolog van, akkor az ember ugyis valami ertelmes programnyelvhez nyul transzformaciohoz. Ha meg csak az alapdolgokhoz jo, akkor mi szukseg van valami uj nyelvszeru dologra. (Gondolkodtam nagykepuen).

Jo, csinaljuk meg Javaban. Kell egy olyan dolog, ami vegigmegy az XML-fan, minden node-nal megkeresi a legjobban illeszkedo szabalyt (az illeszkedest tetszoleges bonyoult XPath-szal definialom), es lefuttatja.

Az hamar eldolt, hogy SAX nem lesz jo, hisz ott az Event fuggvenyek csak string-eket kapnak, a dom poziciorol semmit sem tudnak, es a szabalybol sem tudok kinezni a dom mas agai fele.

Akkor legyen DOM (ugye mindig mas XML kell, schema nem is bitos, hogy van ezert a JAXB, ami szinten DOM szagu, nem jon szamitasba.). A problme az, hogy meg nincsenek meg azok a fuggvenyek, amik a DOM fa kurrens poziciojanak XPath-at ossze tudna vetni egy adott szabaly/listener elore, esetleg teljesen mas alakban megadott szintakszisaval.

Viszont, egyreszt a Xalanban van XSLT motor, ugy hogy o megcsinalja valahogy, illetve van meg az xsltc, ami java byte code-ot fordit xslt-bol (mar jol hangzik). Szoval ilyen iranyban guglizunk tovabb.

Netbeans 5.5 RC1

Igazából csak arról akartam írni, hogy miután sikerült JSF CRUD-ot összelőcsölnöm mindenféle doksi alapján, megtaláltam a Netbeans-ben, hogy DB alapján néhány gombnyomással legenerál ő mindent.

Szóval akkor már: kijött a napokban az RC1. Persze a changelog-ot sehol se találom, mert az már a véglegeshez van, de néhány új code generáló mellett (pl. JMS hívás) találtam pl. Kodo-t és Hibernate-t is a persistence unitok között.

Java persistence api

A mondás az, hogy azért került be csaj az EJB3 JSR alá, hogy gyorsabban át lehessen nyomni a processen. Ezzel szembe akár standalone alkalmazásokba is lehet használni.

A lényege, hogy Pojo entitásokat használ, és egy absztrakt apit definiál, amivel perzisztálni lehet ezeket. Descriptor helyett pedig annotationok vannak a Pojoban.

Szép, egyszerű: ide is rakok egy példát az íze kedvéért:

Az entitás

package jpasample;

import java.io.Serializable;

@javax.persistence.Entity
public class SampleEntity implements Serializable {

    @javax.persistence.Id
    private Long id;
    
    public SampleEntity() {
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public int hashCode() {
        int hash = 0;
        hash += (this.id != null ? this.id.hashCode() : 0);
        return hash;
    }

    public boolean equals(Object object) {
        if (!(object instanceof SampleEntity)) {
            return false;
        }
        SampleEntity other = (SampleEntity)object;
        if (this.id != other.id && (this.id == null || 
                !this.id.equals(other.id))) return false;
        return true;
    }

    public String toString() {
        return "jpasample.SampleEntity[id=" + id + "]";
    }
    
}

A meghívó program már egy kicsit bonyolultabb, de csak a tranzakció és kivétel kezelés szórta meg nagyon.

package jpasample;

import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;

public class Main {
    
    //private static EntityManagerFactory emf = 
       Persistence.createEntityManagerFactory("TopLinkPU");
    private static EntityManagerFactory emf = 
       Persistence.createEntityManagerFactory("HibernatePU");
    
    public static void main(String[] args) {
        new Main().run();
    }
    
    public void run(){
        
        EntityManager em = emf.createEntityManager();
        SampleEntity entity = em.find(SampleEntity.class,1l);
        if (entity==null){
            System.out.println("nincs ilyen");
            entity = new SampleEntity();
            entity.setId(1l);
            em.getTransaction().begin();
            try {
                em.persist(entity);
                em.getTransaction().commit();
            } catch (Exception e) {
                e.printStackTrace();
                em.getTransaction().rollback();
            } 
        } else {
             System.out.println("van ilyen");
             em.getTransaction().begin();
            try {
                em.remove(entity);
                em.getTransaction().commit();
            } catch (Exception e) {
                e.printStackTrace();
                em.getTransaction().rollback();
            } 
            
        }
        em.close();
    }
}

És persze kell hozzá még egy descriptor is, hogy melyik Persistence Api implementációt használjuk:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence 
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
    <persistence-unit name="TopLinkPU" transaction-type="RESOURCE_LOCAL">
  <provider>
  oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider
  </provider>
        <class>jpasample.SampleEntity</class>
        <properties>
            <!--<property name="toplink.jdbc.url" value="jdbc:derby:asd;create=true"/>-->
            <property name="toplink.jdbc.url" 
                         value="jdbc:derby:asd"/>
            <property name="toplink.jdbc.user" 
                         value=""/>
            <property name="toplink.jdbc.driver" 
                         value="org.apache.derby.jdbc.EmbeddedDriver"/>
            <property name="toplink.jdbc.password" 
                         value=""/>
            <!--<property name="toplink.ddl-generation" 
                         value="create-tables"/>-->
            <property name="toplink.jdbc.url" 
                         value="jdbc:derby:asd;create=true"/>
        </properties>
    </persistence-unit>
    <persistence-unit name="HibernatePU"
        transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <class>jpasample.SampleEntity</class>
        <properties>
            <property name="hibernate.connection.url" 
                         value="jdbc:derby:asd;create=true"/>
            <property name="hibernate.connection.driver_class" 
                         value="org.apache.derby.jdbc.EmbeddedDriver"/>
            <property name="hibernate.connection.password"
                         value=""/>
            <property name="hibernate.connection.username"
                         value=""/>
        </properties>
    </persistence-unit>
</persistence>

A NetBeans (5.5 beta 2), amivel ezekenek a kódoknak a nagyrészét generáltam az Oracle TopLink Essential-ját használja. De látható, hogy Hibernate Entity Manager-rel is ment a dolog szépen, csak az EntityManagerFactory konstruktorában kell más persistence-szre hivatkozni. És ez azért nagy királyság: kész a program, de még cserélgethetem a persistence megoldást, hogy megmérjem melyik jobb nekem.

Alapvetően egyébként a JDO is hasonló lehet (múltkor belelapoztam egy könyvbe), elvileg meg is van ígérve, hogy a két speckót egyesítik. De a JPA mellett szól az is, hogy az EJB3 pihepuha Entity Bean-jei is ezt használják.

internet updater

Szeretnék egy standalone Swing alkalmazásban internetes software update lehetőséget tenni. (Illetve csak érdekel, hogy lehetne megoldani.)

Hiába túrom az internetet, seholse találom, hogy lenne rá előre kész megoldás. Van a web start, de nekem nem az kell. Tudom, hogy a JVM magát tudja, de nekem az se jó. Más találat nem érkezik.

Az egyetlen megoldás eddig amit találtam, hogy Eclipse vagy NetBeans platform alá vonulok, de én ennél pehelysúlyubb megoldást keresek. Esetleg látott már valaki ilyen frameworkot?

JSF (IoC)

Az IoC-s huhogásom visszavonva, megtaláltam rá a megoldást. A faces-config.xml-ben vidáman lehet egymásra hivatkozni a beanekkel:

   <managed-bean>
        <managed-bean-name>RecipeAction</managed-bean-name>
        <managed-bean-class>recept.RecipeAction</managed-bean-class>
        <managed-bean-scope>request</managed-bean-scope>
        <managed-property>
            <property-name>recipe</property-name>
            <value>#{recipeDTO}</value>
        </managed-property>

    </managed-bean>
    <managed-bean>
        <managed-bean-name>recipeDTO</managed-bean-name>
        <managed-bean-class>recept.RecipeDTO</managed-bean-class>
        <managed-bean-scope>request</managed-bean-scope>
    </managed-bean>

Azaz a RecipeAction recipe metódusába a setteren keresztül szépen belemegy egy recipeDTO (mivel request scope, ezért mindig újra létrejön egy új és azt rakja be).

Lesz ebből még valami.

JSF (part 1)

A napi adag mellett végre talán megint lesz egy kis időm tovább nézni a JSF-t, de előtte gyorsan leírom az eddigi tapasztalatokat:

A kontextus: azt mindenhol mondják, hogy a JSF szép fastruktúra, a web komponensek hasonlóan felépítenek egy fát, mint mondjuk a Swing-ben. Adatok beküldésekor, validálásakor, rendereléskor, minden node a saját részét csinálja meg. Ami nekem új volt, hogy a másik alapvető dolog, hogy vannak POJO bean-ek (xml-ben definiálva, hogy application, session vagy request scope-pal működnek.) Ezeknek a bean-eknek az egyes attributumait (de néha a függvényeit is) hozzá lehet rendelni a fa komponenseihez. (Tipikusan mondjuk formhoz). Ez az EL-hez hasonló szintakszissal megy, csak $ helyett #-el.

Pl. meg lehet csinálni, hogy egy form mögé rakok egy bean-t, és submit-kor az egész bean kitöltődik a request adatokkal. Rögtön tehetem session scope-ú bean-be is, és akkor már is elraktam a session-ba a bemeneti adatot (persze a validálás után).

Minták: A gond nálam ott bonyolódott el, hogy bármelyik form bármelyik eleméhez lehet bindelni. Ezzel nagyon szép kaotikus dolgokat lehet csinálni. Én pl. szívesen tanulmányoznék néhány mintát, hogy hogy lehet viszonylag normálisan összekötögetni a dolgokat, hogy valamiféle szétválasztása a rétegeknek megmaradjon.

IoC Ehhez kapcsolódik, hogy nekem, aki a Spring IoC konténerén szocializálódott, egy kicsit kaotikus volt. Egyrészt, hogy minden bean-t össze drótozunk minden formmal, másrészt, hogy a a beanek is egymással statikus gyártófüggvény szerű dologból lekérhetőek. Nem tudom miért nincs benne egy kicsit több IoC szellem. Talán meg kéne néznem a Spring integrációt is.

A doksi: az apit és a taglibrary doksit nézegettem, de néha elég nehéz volt kideríteni belőle dolgokat (pl. hogy működik a dataTable). Aztán most nézem a speckót, úgy tűnik az én hibám, mert teljesen más helyen kellett volna kereseni. Azért sokat segítene egy almanac szerű oldal.

ui: ja és semmi Creator csak Netbeans, ez nagyon fontos

Folyt köv.

Session cookie

Jó dolog ez a jcp igazán, szórakozásnak se utolsó olvasni a specifikációkat és a szavazásokat. Hanem az kezd igazan jo lenni, amikor kevésnek bizonyul speckó.

Pl. szeretnék olyan session-t, ami megmarad 1 napig, mégha a böngészőt be is zárom. Ezt nem tudom (eddig nem sikerült) megcsinálnom. A session cookie ugyanis Expired kitétel nélkül jön le, tehát addig él, ameddig a böngészőmet bezárom. (Legalább is ez a tapasztalatom. A 2.4-es Servlet speckóból semit sem találtam az ügyre vonatkozóan).

A session cookie-t nem lehet lekérdezni az apival (bár gyártó függő csomagok néha vannak, de azt ugye azért mégsem). Tehát nem marad semmi eszközöm arra, hogy befolyásoljam a session cookie életét.

Előszőr arra gondoltam, hogy valami Listenerrel megfogom a requesteket, és amikor új session(isNew) van, akkor megfogom a cookie-t. De hamar rajottem, hogy ehhez a request (amibol a session jön) es a response (amibe a cookie-kat dobaljuk) is kell.

Akkor jott a filter. Ott megvan mindkettő, de tüzetesebben vizsgálva szembeötlő, hogy a Cookie-kat csak befele dobalni tudom lekérni egyáltalan nem. Na erre hamarabb is rájöhettem volna.

Akkor csinálok egy HttpServletResponseWrapper-t a filterben es azt adom tovább a chain-nak és a setCookie metodusaban árgus szemekkel figyelek: ezt is hiába, mert semmi nem törtenik. Valószinűleg a hasznalt implementáció közvetlenül a writer-be nyomta bele a cookie headert. Vegül is senki nem irja elő, hogy a setCookie-t kell használni.

Na itt adtam fel. Talán még az lenne megoldas, hogy egy Wrapper osztállyal az egész Response outputot bufferelem, ha még nem volt session, és a végen parsolom a header-t. Na de ez már olyan nagy áldozat lenne, hogy inkább alábbadok az igenyeimből. (Vagy ilyenkor kene hozzaszolni a JSR-hez?)

Sun Java Studio Creator

Nem tudom pontosan mikor, de csak néhány napja, hogy a legfrissebb javításokkal a fenti program más tapasztalatai szerint 50-90%-ékkal gyorsabb lett. Ennek örömére újra megpróbáltam és tényleg javítottak rajta.

Bár én inkább annak örülten, hogy a most letöltött változat végre hajlandó Ubuntu alatt is elindulni. (Kb 3 hónapja még a projekt létrehozásakor széthallt az egész és hosszas guglizás és bugreportolás sem segített).

Egyébkén a fenti tapsztalatok (mármint hogy gyorsabb) nem az enyémek, hanem csak hallomás, és azt is mondták, hogy bugos-bugos, de már nagyon jól használható.

Hát nem tudom. A visual összerakóját én inkább fentartásokkal kezelném, de azt hiszem a JSF-be most már mindenképpen bele kéne mélyednem egy kicsit.

JavaBeans és O/R mapping

Ülök az ablak mellet és a tájat nézem. A JavaBeans-eken elmélkedem.

Egy kevéssé típusos nyelvben olyat is láttunk már hogy lekérdezés előtt az sql query-t keresztül eregették néhány kiterjesztő modulon valamilyen hook rendszer segítségével, és mindegyik modul átformálta úgy a lekérdezést, ahogy ő szerette volna (pl. hozzácsapott valamit). A választ meg majd szintén keresztül eregették a hook systemen, és minden modul szemezgetett 
belőle, és felhasználta az eredményben a kapott plusz mezőket.

Ez eddig nem nagy szám. Javaban is meg lehet ezt csinálni. Mondjuk én szívem szerint kipróbálnám, hogy nem a query String referenciáját küldeném át (ez a String viselkedése miatt nem is lenne annyira jó) hanem csinálnék egy Query osztályt, amihez tagfüggvényekkel tudnék hozzáadni plusz WHERE, ORDER BY stb. feltételeket.

Aztán megkapnám az eredményt. Ez is száll ágról ágra, és minden modul ki tudná venni pl. res.getString("plusz mező")-vel plusz oszlopokat a ResultSet-ből, amiket az sql módosításával ő biztosított magának.

A probléma ott van, hogy múltkor elkezdtem O/R mapping-gel kísérletezni, és az első egyszerű példák valóban nagyon kellemesen kézbe símultak. Csakhogy O/R mapping-gel az adatbázis válasz struktúráját beledrótozzuk a bean osztály szerkezetébe, amit nem fogunk tudni sehogy sem kiterjeszteni (a leszármaztatás már rögtön a több modulnál elvérzik, de az interface implementálás sem járható út).

Őszintén szólva nem ismerem ilyen mélyen az O/R mapping megoldásokat, hogy erre milyen megoldásokat ismer. Két dolog kéne

• egyrészt, hogy a lekérdezéskor ki lehessen terjeszteni az (?)SQL lekérést plusz WHERE, JOIN stb. feltételekkel
  
• és az így kapott plusz mezőket valahol visszaadja

Pl. visszaadhatna egy bean helyett egy bean tömböt (legyen mondjuk Map). A tömb elemeiért (amik egyenkén JavaBean-ek) különböző modulok felelősek, és az alapmodulnak nem kell tudnia a kiterjesztés plusz bean fragmentumairól. Csak persze akkor meg az lesz a kérdés, hogy honnan 
tudjuk, hogy a lekérdezésnek az egyes oszlopaiból melyiket melyik JavaBean-be dobjuk szét.

Nem tudom sikerült-e jól artikulálnom a problémát, de szerintem elég szerény kívánalom. Talán tudja is valamelyik O/R mapping cucc, csak sokkal mélyebben el kéne olvasni a doksikat.