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)