Java Technics

jtechnics.anzix.net

2008-09-25T23:49:00.002+02:00

El vagyunk költözve. (Elvileg már rég azon a domainen működött minden, de most a motor is változott bogger.com-ról WP-re.)

Next Season

2008-08-27T09:10:00.004+02:00

Vissza a satupadhoz. A legaktuálisabban futó dolgok:

1. Indul a JUM második évadja, lassan beindul a szervezés. Előadókat keresünk villám- és nagyelőadás kategóriákban.

2. Nyáron elég sokat szöszöltem egy CLDC 1.0/MIDP 1.0 programmal (ne nevess, az én telefonomon csak ez fut), ami a BKV menetrendet jeleníti meg, és útvonaltervet számol. (Helló Dijkstra). Csak a környékbeli buszok/villamosok vannak bent (mintegy 10-12 járat), de azokra meglepően használható sebességgel számol. Sajnos a BKV most variálja át a teljes menetrendet, szeptember 6-ig várni kell, hogy újra érvényes változatot tudjak buildelni. Addig pár apró hibát ki kell javítani, és majd a menetrendeket frissíteni.

Úgy tűnik simán el tud futni pl. egy teljes éjszakai menetrend egy primitív mobilon is (egy Symbian-on, meg talán a teljes is)

3. Véletlenül hozzájutottam az Effective Java második kiadásához Joshua Bloch-tól. A Java One-on állítólag ez volt az egyik legkeresettebb könyv, és az első néhány lap után tényleg izgalmasnak tűnik. Remélem marad időm tovább jutni benne.

GregorSamsa

2008-07-17T09:11:00.003+02:00

   /**  
     * As Gregor Samsa awoke one morning from uneasy dreams he found himself 
     * transformed in his bed into a gigantic insect. He was lying on his hard, 
     * as it were armour plated, back, and if he lifted his head a little he 
     * could see his big, brown belly divided into stiff, arched segments, on 
     * top of which the bed quilt could hardly keep in position and was about 
     * to slide off completely. His numerous legs, which were pitifully thin 
     * compared to the rest of his bulk, waved helplessly before his eyes. 
     * "What has happened to me?", he thought. It was no dream.... 
     */
    protected final static String DEFAULT_TRANSLET_NAME = "GregorSamsa";

(Részlet a hatos JDK-forrásából (Igazából Apache-Xalan örökség, de benne van))

Sun fejlesztői nap (aka. Open Source konferencia)

2008-06-17T10:40:00.001+02:00

Előszőr is a szervezésről. A biciklivel érkezők pólót kapnak, őrzött biciklitároló, a parkban kint sörasztalok kávézás/ebéd idejére, a szünetekben kivetítőkön JavaOne videók, stb. Lehet, hogy én könnyen megvehető vagyok, de mindenesetre néhány ilyen ötlet után már azt érzem, hogy itt nem csak egy éves rutinrendezvényről van szó, hanem a szervezők tényleg leültek gondolkodni, hogy mivel tudnák jobbá tenni a rendezvényt. Kis dolgok, de mintha fontos lenne az egész, hogy ott vagyok. Én ugyan a tavalyi hasonló rendezvényen voltam előszőr, de azt az idei magasan felülmúlta.

Az előadások. Ide persze jön a szokásos mantra. Kezdek rájönni, hogy nem az előadásokkal van a baj, hanem velem. Én nem a tipikus konferencia előadásokat szeretem, hanem a technológiai szőrözéseket, amikre viszont nem az ilyen konferenciá való, hanem inkább a JUG találkozók. Pl. az általános MySQL előadás helyett sokkal szívesebben hallgattam volna olyan előadást, mint pl. a Boros Péter tartott a Solaris virtualizációjáról (Ami a sok kérdés alapján nem csak nekem jött be megint).

(Kitérő: Arra jöttem rá, hogy engem egyáltalán nem zavar, ha nem tudom, hogy pontosan hogy néz ki az i386 architektúra, és hogy működik a privilégium szintek közötti átjárás. Nem kell minden részletében elmagyarázni. Az előadásból kb. így is megtudom, hogy mire megy ki a játék és mi lehet a probléma. A logikája a dolgoknak átjött. Talán jobb is néha a közönség ismeretanyagának fölé lőni mint alá.

Vagy nem.)

A másik, aminek mindeképpen utána kéne nézni az a DTrace Advanced Visualisation Environment (DAVE), amit Simon Ritter demózot, de egyelőre még nem találtam meg a letölthető forráskódját. Aki nem lett volna ott, ez egy Swing-es alkalmazás, ami egy Java programból DTrace-el kigyüjtött infókat vizualizálja. A Demóban pl. egy gráfot láttunk, ahol a csúcsok az osztályok függvényei voltak az élek pedig a hívás láncolat. (Plusz egyéb infók, hogy mit hányszor).

A Kaukázus koncert meg méltó zárása volt a napnak. Mert igen, én kalapot emelek, ha az egyik legnagyobb IT cég meghív egy zenekart, aki köztudottan globalzicáció és kapitalizmus kritikájú számokat (is) ad elő. Mintha tényleg nem csak üzlet lenne az Open Source, hanem valami más is. És igen, csak jobb lett a hangulat, hogy amíg a JAVA nagy része fent ült a lelátón, a + YOU pedig bement a zenekar elé táncolni.

Most pedig belinkelek egy YouTube videót, mert az nem is blog, aki nem is tesz meg. Mégha nem is ez a kedvenc számom, hallgassatok Kaukázust.

Disclaimer: amikor nincs más választásom biciklivel járok munkába (és legtöbsször nincs más választásom), és jó párszor hallgatok a Kaukázust (és legtöbbször jópárszor). DE: egy volt kolegának is ez nap volt az apropó, hogy kölcsön kérjen egy biciklit és tekerjen a városba, és a koncert után fogadkozott, hogy másnap letölti. Igaz, egy másik kolega viszont csak délelőtt volt, de pont a konkrétumokat hiányolta az előadásokból, meg az új infókat.

Jazoon or not Jazoon

2008-06-04T20:32:00.001+02:00

Ha jól számolom 17 nap múlva kezdődik a Jazoon, ami a JavaPolis mellett a másik legnagyobb Java-s konferencia Európában. Azonban míg tavaly a munkahelyem hívott meg a TSS Symposium-ra, most ha mennék az utazást/szállást mindenképpen fizetnem kéne (a regisztrációra JUM révén lehetne kedvezmény kapni).

Úgy hogy most azon gondolkozom megérne-e nekem egy utazást egy ilyen esemény. Érdemes-e egyáltalán konferenciára járni? Mondanak ott olyat, amit nem lehet megtudni jóval előbb blog-okból és demókból (vagy utána a publikált fóliákból/videókból)?

A tapasztalatom az, hogy az ilyen eseményeken, általában általános bevezető jellegű előadásokat tartanak, ami akkor jó, ha még semmit nem hallottál a témáról, de továbbképzésnek sokkal kevésbé alkalmas. Persze nem jártam még olyan sok Java konferencián (az igazat megvalva még csak egyen voltam), nem tudom általában milyenek.

Nézzük előszőr is a programot, mire mennék el:

Első nap:

Az első előadás-körben nincs olyan, ami nagyon csábítana a pontos érkezésre. OpenID és GWT, de ezekről már túl sok előadást hallottam. A következő kör már többet ígér: szó lehet SAML-ról, amivel régóta szertnék részletesebben foglalkozni, de a buzzword gyanús Scala, Ruby, Erlang vs. Java tematikájú előadás is izgalmas lehet.

Aztán ismét nehéz választani. Jobb híján egy DSL vagy egy Comet előadásra ülnék be valószínűleg. Végül a nap zárásaként egy Swing Application Framework teljesen jó választásnak tűnik.

Második nap:

Itt már újra a bőség miatt nehéz a választás. A Parleys.com-os előadás (JavaFX, Flex, AIR) állítólag már a J1 en is nagyon jó volt, de az Agile Testing-en kívül mindegyik érdekel (Spring 2.5, JAX-RS, JBI ). Utána egy JCR 2.0 lenne a választott. Aztán megint jobb híján ülnék be a Glassfish v3 Integration Profile-ra. A következő lehet a WS-TX, és utána megint semmi. Esetleg a JavaFX vége.

Harmadik nap:

Az első két előadást azt hiszem a Grails-es duplával tudnám legkielégítőbben letudni.
A délután meg valószínű Java Puzzlers és eBay architectura lenne benne.

A választék tehát közepesen erős. És vannak még a BOF-ok, amikre azonban még mindig lehet jelentkezni, ezért semmit nem lehet róluk tudni, pedig azok még jók szoktak lenni.

Annyira azonban nem erős, hogy egyértelműen eldöntse a kérdést: megéri-e a pénzt és a fáradságot, vagy inkább vegyek ki helyette egy hét szabadságot, és csináljak meg végre néhány régen tervezett prototípust...

Toplink bug II.

2008-05-28T17:14:00.002+02:00

Újabb szép Toplink Essentials bug vett el egy (eddig) egy napot a projektünkből. Prototípus projektet még nem sikerült csinálni, de jól reprodukálható, és ismét a leszármaztotott osztályok mint entitások körül van a gikszer, csak most a belső cache táján. A szépségét jól jelzi az, hogy ha a tesztelés két lépése között újraindítom a Glassfish-t, akkor minden megy, ha nem, akkor OptimisticLocking exceptiont kapok. Előtte mg utána csak persiste és find-van, de a find hol a szülő, hogy a gyerek entitásra keres rá.

A workaround egyelőre a Toplink level 2 cache-nek kikapcsolása:

<property name="eclipselink.cache.shared.default" value="false"/>

De most épp valami hasonló hiba néz ki a kódból, amit még nem derítettünk fel, úgyhogy lehet, hogy ez se segít. Egyébként EclipseLinke M7-tel a helyzett ugyanez. Lehet, hogy Hibernate JPA-val is ki kéne próbálni, de az meg a kissé bonyolult entitás struktúránkba hal bele (Bizonyos dolgokat annotációval, másokat XML-ből állítunk be).

WTF: Interface Equinox módra

2008-05-19T21:09:00.003+02:00

Sajnos az OSGi nem tartalmaz szabványos interface-t a konzol szolgáltatásokra. Konzolja azonban szinte minden OSGi frameworknek van, és általában ezeket valahogy ki is lehet terjeszteni, hogy saját parancsaiddal bővítsd a rendszert.

A Felix-ben pl. a SehllSerivce-t kell implementálni:

public interface ShellService
{
    public String[] getCommands();
    public String getCommandUsage(String name);
    public String getCommandDescription(String name);
    public ServiceReference getCommandReference(String name);
    public void executeCommand(
        String commandLine, PrintStream out, PrintStream err)
        throws Exception;
}

Ez a dokumentáció nélkül is körülbelül érhető. De hogy csinálja mindezt az Equinox?

Nos előszőr is implementálni kell egy CommandProvider interface-t. Ezek után pedig minden metódus, ahol a metódusnév _-al (aláhúzással) kezdődik automatikusa a konzolból is elérhető parancs lesz. Az én konzervatív OOP-s lelkemnek ez már határeset.
Jó, jó, legyen egyszerű, de nem gányolás ez kicsit?

Java PDF2HTML

2008-05-15T16:29:00.002+02:00

A mai nap egy régi XSL-FO-s rendszert kellett volna újraéleszteni az új környezetbe, hogy HTML-t PDF-en keresztül tegyünk szépen nyomtathatóvá.

Biztos ami biztos előtte azért körbenéztem, és azt találtam, hogy létezik egyszerűbb megoldás is. Pl. az xhtmlrenderer pont tudja ezt iText-en keresztül.

Van hozzá egy jó részletes cikk, és azt kell mondanom, hogy tényleg működik. A prototípus probléma nélkül csinálja a dolgát (pedig még némi iText varázslattal meg van bonyolítva).

Szóval eddig jó, remélem a UseCase-ek implementálása közben is ugyanilyen elégedett leszek.

JUM számvetés

2008-05-14T01:27:00.005+02:00

Egyéves a JUM: hazánk leg Java User Group-osabb Javas rendezvénysorozata. Egy év alatt hat alkalom, 21 előadás (ha jól számoltam): a mérleg pozitív. A továbbiakhoz azonban nekem mindeképp igényem lenne egy számvetésre, hogy hol mit kéne jobban csinálni. Vitaindítónak az alábbiakban foglalom össze saját észrevételeimet.

Helyszín: erre szerintem nem lehet panasz. Krisztiánnak sikerült mindig előre pontosan mindent elintézni, csak újfent megköszönni lehet a Sztakinak a támogatást.

Lebonyolítás: itt már van mit javítani. Szerintem nagyon hiányzott alkalmanként egy moderátor aki:

elmondja az elején a napirendet
utána betartatja (ne legyen túl hosszú szünet, esetleg ne legyen egyáltalán, maradjon feszes a program)
Az előadásokat is moderálja, leállítja, ha nagyon túlfut az időből stb.

Valahogy úgy alakult, hogy ilyen nem volt (eleinte aki csinálhatott volna ilyet, az elő is adott, később meg nem alakult ki). Szerintem szükség volna rá, akár úgy is, hogy minden alkalommal más válalja el.

Az hogy beálltunk a kéthavonta fix időpontra az mindenképpen okos dolog volt.

Előadások: ez szerintem az egyik legfontosabb kérdés. Az eredeti elképzelés valami unconference jellegű dolog volt, ahol:

mindenki előadhat, aki jelentkezik
hangsúlyosan saját tapasztalatokról kell beszélni (vér, verejték, izzadság)

Sajnos azonban a rendszer nem vált be teljesen. Egyrészt nehéz volt jelentkezőt találni. Aztán kiderült az is, hogy ha valakinek komoly tapasztalata van egy témában, az még nem biztos, hogy jól el is tudja mondani azt. Néha még az is eszembe jut, hogy olyan emberből akit én elképzeltem, talán nincs is olyan sok.

A legfontosabb szerintem amin változtatni kell az az előadásól színvonala. Bármit is jaívtunk a többi pontnál, ha nincsenek színvonalas/profi előadásaink, akkor nem érdemes csinálni. Nem érdemes közönséget szerezni, stb.

Több út is van:

A JUG-ok szerte a világban általában egy hosszabb meghívott előadóval dolgoznak alkalmanként.
A mi eredeti célkitűzésünkhez, ami sokkal inkább unconference jellegű volt, jobban passzol a több rövidebb előadás.
Ennek a másik oldala a Meetup jellegű tízperces előadás, ami bizonyos esetekben adekvát lehet (ezt Kocka próbálta megjeleníteni), de egy ismeretlen technológia előnyeit, hátrányait, és a róla szerzett tapasztaltokat, szerintem nem lehet hatékonyan tíz perc alatt elmondani.

Nem látom igazán még megfelelő módszert. Volt olyan ötletem is, hogy a résztvevői, bemutató előadásokhoz kötelező legyen prototípust csinálni (Kocka legjobb előadása szerintem a legutóbbi Flex-es volt, amihez már előzőleg publikálta a prototípust). Ha van prototípus, sokkal könnyebb bemutatni, az egy biztos vezérfonal. De létezhetnek olyan elméletibb témák, amihez lehetetlen prototípust csinálni.

Szerintem azt is jó lenne, hogy ha megkeresnénk azokat a magyar fejlesztőket, akik nemzetközi OS projektekben dolgoznak, és őket meghívnánk, hogy beszéljenek a saját projektjükről (meglepően sok ilyen van).

Lehetne esetleg valami szavazás/feedback-et csinálni alkalmanként, de ha mondjuk a 20 résztvevő harmada kitölt egy kérdőívet, az már nem biztos, hogy számottevő minta.

(Itt azért megjegyezném, hogy voltak nagyon jó előadások is, és talán nem volt olyan alkalom, hogy ne lett volna olyan, ami miatt ne lett volna érdemes elmennem, de ez, úgy érzem, még kevés).

Infrastruktúra: A másik olyan pont, amit nem kezeltünk elég jól. Van egy honlap (jum.hu), de nem mindig frissült elég gyorsan. Van rajta hírlevlél, ami nem mindig ment ki időben. A fóliákat nem szedtük össze, a videók bár elkészültek, nem kerültek fel sehová, stb. Ezeken mindenképpen változtatni kell.

Marketing: Eddig azt hiszem javaforum-on, és a java listán volt hirdetve, és így körülbelül 15-20 ember jött el egy alkalomra (ritkán több, néha kevesebb). Kérdés, hogy fontos-e, hogy többen legyünk, kell-e a hirdetésre nagyobb energiákat fektetni.

Egyrészt, ha a tapasztalatok megosztását önmagában hasznosnak tartjuk, akkor elvileg ha csak öten vagyunk az is jó.
Másrészt ha akarunk hívni meghívott előadókat, akkor illik legalább valamennyi közönséget prezentálni. (Ajánlkozott előadó külföldről is, de 20 ember miatt talán kicsit túlzás idehívni).

Itt is lehetnek ötletek, pl. a Java fejlesztő bázissal rendelkező cégek vagy egyetemek megkeresése.

A javaslat: A következő alkalom (május 21) nem lennének Java-s előadások (itt nem részletezett szervezési okok miatt se), hanem helyette a fenti témákról lenne egy hogyantovább vita/beszélgetés/ötletelés. Ezt ugyanúgy meghirdetnénk, mint bármelyik más alkalmat (mindenki jöjjön, akit érdekel egy kicsit is a rendezvény/egy működő magyar JUG jövője). Viszont most vissza kell jelezni, mert a létszám függvényében szerzünk termet. Ha kevesen vagyunk, akkor esetleg vendéglátó ipari egység is szóbe kerül, de ott is az elején szigorú napirend szerinti megbeszélést tartunk a jövő évről. Tehát aki jönne, az íron egy levelet az info kukac jum pont hu-ra, és jövő hét elején kitaláljuk a helyszínt.

További OSGi tapasztalatok

2008-05-12T20:52:00.001+02:00

OSGi-val való további ismerkedés keretében csináltam egy remek Jabber / XMPP OSGI kozol bundle-t. A lényege, hogy nem csak op rendsze parancssorából indított OSGi framework konzoljából pásztorolhatjuk a framework konzolját, hanem Jabberen keresztül is. (Bundle-k listázása, leállítása, stb.)

Egy érdekes dolog, hogy konzolos parancsokhoz nincs szabványos OSGi interface, ezért az összes framework külön talált rá megoldást (én eddig a Felix és az Equinox alá implementáltam a bundlet). Ebben az a szép, hogy a pluginem kódja, az Equinox és a Felix bizonyos osztályaitól is függ fordítás szinten, de futás szinten csak akkor fog ráfutni olyan kódra, ahol Felix specifikus osztályokat használok, ha létezik olyan beregisztrált service (a servicek String névre vannak regisztrálva, a létezés az osztály nélkül is ellenőrizhető). Azt kell mondjam, az OSGi koncepció működik.

Fejlesztéshez a pax-construct maven plugint használtam (Ami használja a Felix bundle plugin-t is). Viszonylag kis szívás volt vele, csak egyszer kezdtem el debugolni, de akkor is kiderült, hogy felesleges volt, a Felix bundle dokumentációját kellett volna jobban átnyálazni. A fenti Classloader-es trükhöz kell ugyanis finomhangolt Import-Package leírót gyártatni, hogy a framework függőségek csak opcionálisak legyenek.

(Zárójeles megjegyzés: amilyen csapnivaló volt a NetBeans 6.1 Beta Maven pluginje, a végleges annyira meggyőző. Pl. most már olyat is tud, hogy ha egy ismeretlen osztályt lát, akkor egy klikkre felajánlja a központi repository-ból azokat az artifactokat, amik tartalmaznak ilyen nevű osztályokat. És mivel már a Glassfish 3 TP és az OpenESB 3 fejlesztés is Maven-be megy, úgy hogy a NetBeans Maven támogatás csak jobb lesz ennél.)

Szóval jó kis játék volt, lehet hogy feltolom Google Code alá. Szinte ugyanannyi ott projektet létrehozni, mint a saját szerveren belőni SVN-t.

Testablility Explorer

2008-05-09T08:08:00.000+02:00

A testability explorer (nem meglepő módon) egy kód tesztelhetőségét hivatott vizsgálni. Van egy publikus demó oldal is, ahol néhány OS projekt tesztelhetőségét publikálják. (pl. itt az ANT 1.7-é).

Első látásra teljesen elvarászolt, de aztán kiderült, hogy igazából semmi új, csak a Cyclomatic Compexity-t viszgálja, plusz az írható globális mezők értékét (Counts the number of fields which are globally reachable by the class under test and which are mutable.)

A Cyclomatic Compexity egy mérőszám, ami megmondja, hogy mennyi különböző lefutása lehet egy metódusnak. Ha pl. van benne egy darab if, ami vagy igen vagy nem, az már két lefutás. Minnél több lefutása lehetséges, annál nehezebb tesztelni. Nem nagy truváj, a PMD is mér ilyet. Most már inkább az érdekel, hogy hogy méri mindezt az ASM segítségével. Ha lesz időm játszanom kell majd vele egy kicsit.

(Via: Az eszközre Alex Miller bejegyzésén keresztül találtam rá amit Eugene Kuleshov BOF sessionjéről írt. )

Java One messziről

2008-05-07T10:37:00.004+02:00

Nem tudom miért pont idén, de valahogy a JavaOne résztvevői most kattantak rá a Twitterre, és jó nagy zajjal tudósítanak is róla. Már maga az vicces, hogy ilyen commenteket olvashatok:

(stevegio): I think I'm going to avoid all javaone sessions whose descriptions begin with the letters 'JSR'

De persze a legértékesebbek a linkek, már vagy 3-4 jó independent Java blogot találtam, meg pl. egy Java-ba írt Quake implementációt.

Amúgy az még nem jött le, hogy lett volna nagy bejelentés. Állítólag ugyan van JavaFX roadmap, de még nem találtam meg.

UPDATE: Google bácsi kisegített.
Sun set forth a road map for JavaFX:

* In July, Sun will open the JavaFX Desktop SDK Early Access Program
* In the fall, JavaFX Desktop 1.0 ships.
* In the spring of 2009, the JavaFX Mobile and TV 1.0 variants will ship.

web.conf.hu 2008

2008-04-27T18:15:00.003+02:00

Tavaly még az volt a stratégiám, hogy beüljek az összes Java-s előadásra, ez mára megváltozott. A Java-s témákról általában hallottam/tudtam már, gondoltam szétnézek a maradék részben, találok-e érdekeset.

1. Szalai Ferenc: Felhaszáló központú és föderatív azonosítási megoldások web alkalmazásokban
Ehelyett még JavaFX demókat nézhettem volna, de a szervezés ide kötött (innen szereztem laptopot). Alapvetően jól összeszedett előadás volt, bár most is felmerült bennem, hogy miért szükségszerű, hogy minden OpenID-s előadás Dick Hardt: Identity 2.0-s előadásának a stílusát akarja másolni. Ráadásul, amikor lényegi részekről volt szó, akkor vissza is váltottunk hagyományos stílusra.

Sajnos a Liberty Alliance-ről esett a legkevesebb szó, ami a leginkább érdekelt volna, de amúgy rendben volt.

2. Szentiványi Gábor: Mysql adatbázis technikák. (Még a mikroformátumok felé hajlottam, de belehallgatva a folyosóról, inkább alapozó előadásnak tűnt, nekem kicsit lassú volt).

A Mysql előadás alapvetően Mysql Enterprise/support/oktatás reklám volt. Az előadó stílusa pedig jó lett volna, de engem jobban meggyőztek volna, ha több technikai részletet hallottam volna a Mysql-ről magáról.

3. Sun open source technológiái (Zsemlye Tamás, Boros Péter) Na, gondoltam, ez lesz a másik nagy reklámos előadás, de azért jobb hiján ide ültem be, és akkor se változotak meg az elvárásaim, amikor meghallottam, hogy az előadás második felében az OpenSolarisról fogunk hallani.

Az első részben Zsemlye Tamás sorolta fel a Sun hoz kötődő OpenSource projekteket, majd átadta a a szót Boros Péternek. Kb. tudtam mi fog jönni, ZFS, Zone-ok, stb., láttam már ilyet is. És valóban fóliák helyett két konzol a kivetítőre és elindult a varázslás.

És teljesen elvarázsolt.

Semmi töketlenkedés, csak a parancsok, világosan kommentálva, hogy mi történik, komoly dramaturgiai hátérrel. A kérdéseknél a végén, meg egy jó insider felvetésre olyan precíz és pontos választ kaptunk, hogy csak ülni tudtam és élvezni a fanatizmust és hozzáértést.

Tudom, hogy web konf meg minden, de számomra mégis ez volt a legjobb előadás.

3. Grániz Ádám: Robosztus Webalkalmazás Fejlesztés F#-al Funkcionális programozás. Persze a rövid előadás időbe belezsúfolva, ezért épp csak felvillannak dolgok, számomra nem is nagyon derült ki egy világos példán, hogy mi a különbés és az OOP.

Látszott, hogy az előadó fejében mennyire bent van minden a C#-tól kezdve, viszont úgy tűnt, hogy ez a nagy tudás teljesen diszjunkt a Java világával szemben.

Egyébként a végén valami olyasmi rendszerről volt szó, mint a GWT, csak itt konkrétan egy kódba lehet írni a kliens és szerver oldalt. Meg F#, ami funkcionális, és ahogy írtam nem derült ki számomra benne a truváj, de valószínű utána kéne olvasni.

Amúgy egy kicsit olyan feelingem volt, mint amikor a JRuby és Groovy előadásokat hallgatok, hogy van a stabil nagy testvér, és az agilis ifjú titánok.

4. Varga Péter: Ajaxos fejlesztés NetBeansben jMakival Aztán még hallgattam jMaki-t is barátságból. Szép minták vannak benne, de azért nem győzött meg, hogy a GWT-nél jobb megoldás lenne.

Még elmenetben láttam, hogy a PHP, ahogy nem csináltam előadás tartalmában FastCGI és IIS szavak szerepelnek, de aztán inkább csak tekertem haza (fájós térddel, mivel odafelé csúnyán szétcsúsztam egy villamos sínen.)

Webconf

2008-04-25T16:37:00.004+02:00

Szolgáltai közlemény: Holnap webconf, és én még egyelőre keresek olyan embert, aki ott lesz délelőtt, és egy prezentáció erejéig (meg előtte kipróbálásra) kölcsön tud adni egy laptopot, hogy vetítsek vele. OpenOffice Presentation meg Firefox kéne, esetleg az utóbbiba Firebug. (Köszi, megoldódott).

OSGi első lépések

2008-04-07T23:46:00.001+02:00

A hétvégén volt egy rövid köröm az OSGi-vel. A tapasztalatok címszavakban.

Az apache Felix OSGi konténerével kezdtem, pöccre indul, kicsi, gyors.

Szintén a Felix Maven pluginjével buildeltem az OSGi Bundleket (=modulokat), a plugin igazából csak a Manifest-et tölti ki az OSGi specifikus adatokkal. Nem volt vele különös szívás.

Azt viszont nem sikerült megvalósítani, hogy legyen valami olyan run plugin, ami buildelés után rögtön bedeployolja és futtatja egy futó OSGi rendszerbe a lefordított modult.

Rátaláltam viszont a Pax-Runner-re. Ami szintén egy kicsi és könnyen használható tool OSGi konténer és benne egy modul indítására. Paraméterezhető, hogy melyik konténert indítsa (Felix, Equinox, Knopflerfish, első alkalmmal letölti azt, ami kell), továbbá, hogy honnan vegye a modult, amit indítani kell benne (polloz könyvtárat, leszed modult OSGi repoból, vagy akár Maven repóból). Én ez utóbbit használtam. Installoztam a Maven projectet, majd

pax-runner mvn:net.anzix.osgi/helloworld

Sajnos következő futtatáskor a pax-runner cache-t üríteni kell, hogy újra a Maven repository-ból töltse le az aktuális modult.

Kedvenc Hudson pluginjeIm

2008-04-02T23:10:00.003+02:00

Már lassan több mint három hónapja használjuk nap mint nap a Hudson-t mint CI szervert, és továbbra is meg vagyok elégedve vele. Igazából lehet, hogy más ugyanilyen kényelmes CI szerver is van, én ezzel kezdtem, és ennél maradtam. Az egyik legnagyobb előnye, hogy jól bővíthető, van is hozzá egy rakás plugin. Mi most az alábbiakat használjuk:

Jabber plugin, aki szól nekem rögtön, ha valami nem kóser (emelett persze emailt is küld).
Violations plugin egyelőre csak a PMD eredményeit mutatja grafikonon (meg persze a részletes hibajegyzéket is meglehet nézni). Ha nem is olyan szép design mint a Sonar, de azért elég jól megteszi, és legalább a CI-ben vannak ezek az adatok is.
SCP plugin: a kész artifactokat tolja fel a publikus szerverre (így egy belső gépen buildelhetünk, és az interneten kint lévőn csak az eredmény van.
+1 Nem használjuk, de van még egy említésre méltó plugin az Emotional, ami azt a hasznos funkciót valósítja meg, hogy ha eltörik a build, akkor a Hudson logója (bajszos bácsi) nagyon mogorván néz a háttérben. KIhagyhatatlan :-)

Egyébként a harmadik pontot a Glassfish még viccesebben oldja meg. Ott van egy belső fordító gép park, és az a belső Hudson összes eredményét egy pluginon keresztül egy külső Hudson-ra nyomja ki. Öröm és boldogság.

Flash vs. AJAX

2008-03-31T00:59:00.001+02:00

Kijött a photoshop webes verziója a Photoshop Express. Persze az Adobe-tól, tehát Flash az egész. De mi miatt érdekes ez egy Java-s blogban?

A kérdés az, hogy ha legkevesebb fájdalmat akarom, hogy tudok internetről elérhető használható klienst produkálni egy backendhez. Egyrészt ott van az AJAX és az arra épülő rendszerek, mint pl. a GWT, amit most már jó ideje gyűrök. A másik, hogy kihagyjuk az egész HTML/JavaScript szívást, és az egészet meg csináljuk Flashbe (illetve itt is valami ráépülő varázslattal: OpenLászló, Flex).

Egyrészt az a kérdés, hogy melyik végterméke a gyorsabb/használhatóbb, másrészt, hogy melyik fejlesztése a kényelmesebb, használhatóbb. Az első kérdésre izgalmas a fent belinkelt Photoshop-os oldal, mert eddig még nem használtam olyan full-flash oldalt, ami bonyolultságába a Google Docs-al összemérhető lenne. (Ez összemérhető, de azt kell mondanom, hogy élményben nem jobb, nem rosszabb).

A másik kérdésre nem tudom a választ. AJAX-os megoldást viszonylag kis fájdalommal GWT-n keresztül lehet csinálni Java fejlesztő eszközökkel (+debugolás, +unit testek). De mondjuk a Flex / OpenLászló világba nem tudom milyen ennek megfelelő eszközök vannak (Ingyen, OpenSource-ért.)

Glassfish optimalizáció

2008-03-20T16:58:00.001+01:00

Gyorsan feljegyzem magamnak, hogy miket használtam a Glassfish tunninghoz.
A két gyorstalpaló Jean-Francois Arcand-tól itt és itt olvasható. Alap trükkök csak: a -server használata, GarbageCollector és memória hangolás, és persze a poolok megnövelése. Ezek összességében olyan 15%-os teljesítmény növekedést eredményeztek nálam.

Körülbelül ugyanilyen fontos, hogy az acceptor-threads paramétert (http-listener) annyira állítsuk, ahány processzorunk van (vagy magunk). Core 2 Duo esetén pl. a 2-es érték érezhetően gyorsít, de efelett persze már nem segít.

Kellemes meglepetés az is, hogy a Sun-nak mennyire jó tunning dokuja van a glassfishez (elérhető innen). Nagyon részletes és a triviális változtatások mellett leír egész szép trükköket , még oprendszer szintűeket is.

Ez meg csak egy rövid figyelmeztetés, hogy miért ne az apache ab-vel terheljünk.

Egyébként pedig átlagos Desktop gépeket terhelve (Core2Duo 2-3G ram) egy jsp + custom tag + statless session bean + 1 db JPA query alkalmazással, kb. 1800-2200 lekérés/sec-et sikerült elérni. Statikus html ennek a 2-3 szorosáig simán felmegy. És nagyon nem is foglalkoztam sokat vele, pl. egyáltalán nem néztem meg, hogy itt az adatbázis-e a szűk keresztmetszet.

Maven + Netbeans (6.1 Beta)

2008-03-13T17:11:00.001+01:00

Maven kellett éppen, gondoltam majd a Netbeans-ben, és automatikuasan a Netbeans 6.1 beta-t indítottam. A plugin benne is volt a hivatalos plugin repo-ban, de a telepítés után elég kiábrándító volt. Olyan alap dolgok nem működtek mint pl. az importok automatikus rendbeszedése, arról nem is szólva, hogy a Web-es Maven projekt semmit sem tudott deployolásról vagy web.xml szerkesztésről. Gondoltam is, hogy erről ennyit.

Azért biztos ami biztos kipróbáltam 6.0-val is. Ugyanúgy felugrott, de láss csodát, egész más élmény. Importok működnek pöccre, minde szép és jó, sőt a beépített Tomcat-be és Glassfishbe is zokszó nélkül deployolt. Egész használható volt az egész. Ott volt csak kis szébséghiba, aminek nem értem a nyomára, hogy a checkstyle pluginnek Netbeansben teljesen más verziója (asszem 2.0-beta6) jött le mint command line mvn-nel (2.1). És persze más default beállításokkal dolgozik a kettő.

A nagy örömre jutalmul ki is próbáltam Kocka Flex-es RPC-s prototípusát, és persze ment szépen, bár a kódban még nem volt időm elmélyülni.

Napi GWT

2008-02-28T14:57:00.002+01:00

1. Az anonymous inner classokkal több baj is van:

Nem szerializálhatóak GWT.RPC szerint.
Ha egy ilyenbe egy másik anonymous innder class-t hozol létre, az életbe nem fogsz tudni bele debugolni hosted módban.

2. (vrg találmánya) Tömb rendezése nagy tömböknél iszonyat belassúl. Az a működő megoldás, ha a javascript natív sort-ot hívjuk meg. Valószínű alapból a GWT a Java SE nagyon rafinált de kicsit bonyolult megoldását próbálja javascriptre fordítani.

Challenge 24 tapasztalatok.

2008-02-26T23:18:00.003+01:00

Tapasztalatok:

Bámulatos mi mindent meg lehet oldani brute force-szal.
Meglepő milyen nehéz még brute-force algoritmust is megfogalmazni, ha nem vagyunk járatosak algoritmus elméletben.
Nem voltunk járatosok algoritmus elméletben.
Abszolút felkészületlenek voltunk.
Legközelebb fizikailag egy teremben leszünk, és rászánjuk az időt, hogy minden problémát jól átbeszélünk.
Legközelebb úgy intézzük, hogy a 3 emberből ne csak 2 érjen rá az EC alatt.

Viszont egész lelkesek lettünk az algoritmus elmélet iránt, és most éppen jobbnál jobb megoldások után guglizunk, és utólag megírjuk magunknak a megoldásokat. Most pl. épp a suffix tree napi téma.

Kérdés: Vajon, ha elmélyedünk az algoritmus elméletben, akkor lesz olyan, hogy a napi munkánkban tudni fogjuk ezt használni? (Úgy mint pl. a tervezési mintákat, amik csak előbukkannak a fű alóll, itt-ott).

+1. A szervezőknek minden tisztelet. Teljesen jó volt.

Továbbra is GWT

2008-02-19T23:37:00.003+01:00

A GWT a maga "correct level of abstraction"-jával, azért elég sok kérdést nyitva hagy. Bár lassan alakulnak a frameworkok hozzá, azért ezek még koránt sincsenek kiforva teljesen.

Nekünk most lassan 2-3 hónap projekt tapasztalat után kezdi kiforni magát a saját rendszerünk. Még 1-2 hónap és tényleg neki állhatunk újra írni az egészet, és akkor jó lesz.

A reflectionunkat pl. a gwittir-től loptuk bár egyik tanult kolegám még csavart rajta kicsit. A többi részt viszont nem használjuk belőle, mert bár nagyon jó MVC jellegű felépítése és binding-jai vannak, nekünk egy kicsit komponens alapúbb speciálisabb rendszer kellett. De kezd az látszani, hogy bár nyilván ennek is megvannak a korlátai, azért elég komoly rendszert lehet belőle építeni.

Kis színes

2008-02-14T23:32:00.002+01:00

1. Egyrészt, még a hétvégén Sun Java System Web Server helyett Apache httpd + mod_jk + Glassfish került a szerverre. Ennek örömére rögtön fel is javítottam két régi ROME alkalmazást, és deployoltam. Ez az az napi névnapokat adja feedben. Ez pedig minden napra egy híres ember születés napját adja ki. (A születésnapokat még 5-6 éve gyűjtöttük egy barátommal abból a megfontolásból, hogy tudjuk, hogy melyik nap kire iszunk.)

2. Egy kicsit próbálom hírekkel élénkíteni a jhacks-et. Még nem tudom pontosan mi lesz belőle, mindenesetre a rövid hír jellegű postok ezentúl odamennek (Ha van valakinek jó külföldi/belföldi Java-s blog ajánlata az jöhet, mert nagyon nehéz naponta/kétnaponta értékelhető hírt összeszeni.) Aki még nem bookmarkolta a feedjet, annak ezt is csak ajánlani tudom.

3. Az utolsó pillanatban neveztünk a Challenge24-re a kollektívával. Nem tudom mi lesz belőlre, mert algoritmuselméletből elég támadható vagyok, ide meg az pl. erősen jól jön, de majd még meglátjuk. Még vasárnapig lehet nevezni.

Openfire + Pidgin

2008-02-11T20:14:00.000+01:00

The solution: Use only the first part of your domain in the Domain field (Basic tab) eg. domain and the fully qualified domain name in the Connect Server field (Advanced tab) eg. domain.com.

Ez a fenti csak azok kedvéért, akik a gugliból jönnek a kulcsszóra. Csak, hogy ők se csalódjanak. Egyénként az Openfire nagyon kezes Jabber szerver. Letölt, elindít, és megy. (Csak arra kell vigyázni, hogy ha 8080-as porton valaki figyel, akkor a defaultból bekapcsolt HTTP bind-del összeakad). Van hozzá enterprise is, de az Open Source változat is mindent tud. Van hozzá szép webes admin felület is, kattintgatós.

Sajnos a Pidginnek egy kicsit imádkoni kellett, hogy menjen vele (lásd felül), nem volt időm még tetten érni, de vagy a Pidgin, vagy az Openfire valamelyik hash (talán MD5?) implementációja különbözik.

Hudson

2008-01-31T10:18:00.000+01:00

Szóval ez igazán egy pazar cucc. (Egyébként egy Continous integration eszköz) Régebben (egy két éve) még a Continuum-ot nézegettem, akkor az még csak standalone-ként volt hajlandó futni nekem, és rengeteg adatbázis mütyürészést kellett véghez vinni, hogy elinduljon (azóta talán az is fejlődött). Ellenben ez csupán egy war, amit bedeployolok és megy.

Nálunk így megy: 5 percenként svn update-et nyom és ha változik valami fordít újra egy release-build-et és lefuttatja rajta a unit teszteket (Unitils rulez, ha változik a séma definíció a repositoryban, automatikusan felépít egy új adatbázist).

A Hudson-nak valami olyasmi a filozófiája, hogy én elvégzem a piszkos munkát (Ant-tal, Maven-nel, shell scripttel, bármivel), és ő az eredményt szépen megmutatja. Pl. megmondom neki, hogy az ANT task végén hol lesz az artifact, és ő azt szépen archiválja (nálunk a legutóbbi 10-et), ezek közül meg lehet jelölni bármelyiket hogy ne rotálódjon ki (tipikusan nálunk mindig a legutóbbi 10 build van fent, meg megjelölve az a régebbi, ami épp a megrendelőnél van). És persze, ha szar kerül a palacsintába, akkor email-t ír, telefonál, kárt ment, stb.

A fejlesztője nagyon nyomni akarja, ezért nagyon sűrün vannak belőle release-ek, és az egész interface kellemes hangulatot áraszt. Pl. értelmes hibaüzeneteket ír, és elmondja, hogy mikor mi a baj.

Szóval nem próbáltam végig az összes CI toolt, de ez elsőre nagyon használhatónak tűnt.

Generics + reflecion

2008-01-17T17:05:00.000+01:00

Tegnap ígértemhez híven: a generic típusok a bytecodeban benne vannak a deklarációs részben, csak a utasításoknál nincsenek. Reflecionnal tehát lekérdezhetőek.(Pontos speckó linket most nincs időm keresni, helyette itt a példakód.)

public class Main {

    public List<Double> list;

    public static void main(String[] args) throws Exception {
        Field field = Main.class.getDeclaredField("list");
        ParameterizedType ptype = (ParameterizedType) field.getGenericType();
        Type[] types = ptype.getActualTypeArguments();
        System.out.println(types[0]);
    }
}

Toplink JPA bug

2008-01-11T09:32:00.000+01:00

Mindig öröm, ha egy komoly termékben néhány órás szívással izolálni tudunk egy hibát, és végre kiderül, hogy nem mi voltunk a hibásak. Most az történt, hogy Joined table inheritance strategyt használtunk és left joint és a Toplink Essential a discriminator value-t inner join-nal kezelte. Magyarul nem lehet left joint csinálni, hiába írom be a querybe.. Ki próbáltam Hibernate JPA-val is (ugye milyen jó, hogy hipp-hopp váltogatni lehet a providerek között?), és azzal rendesen ment.

Akkor most bugreport és native queryk használata a bugfixig.

Unitils tapasztalatok

2008-01-07T21:44:00.000+01:00

Régóta nem írtam már ide, pedig jócskán felgyűltek a témák. Az egyik ilyen az Unitils bevezetése az egyik projektünkbe. Az Unitilsnek Kocka egyik blogbejegyzése nyomán kezdem utána nézni.

Az Unitils a Junit3,Junit4 és a TestNG keretrendszerek mindegyikével házasítható, ezeknek a teszt környezeteknek funkcióihoz adnak hozzá a moduljai. A Unitils moduláris felépítésű, mi három modulját használjuk:

database
A database modul egy adott környvtárban található sql szkripteket sasolja. Ha valami is vátozik, akkor az adatbázis teljes sémáját bedarálja, és újra futtatja a szkripteket. Nagyon praktikus olyankor, amikor a sémát SVN-be tároljuk, de többen is szerkesztgetjük.

dbunit
Ez igazából a dbunit-ra egy wrapper modul. a @DataSet és @ExpectedDataSet annotációkkal jelölhetjük meg a teszteinket, és ezekkel adhatnk meg egyszerű XML-eket, amikben a teszthez szükséges adatbázis tartalom van. Pl.

ServiceOneTest.xml
<dataset>
<customer id="1" name="asd">
</dataset>

ServiceOneTest.testOne-result.xml
<dataset>
<customer id="1" name="changed">
</dataset>

Elég kényelmes dolog, de van egy fontos tulajdonsága. Az előző modul a séma létrehozása után alapból az összes constraint-et disabled-re állítja. Ez egyfelől kényelmes, mert az XML-ekben tényleg csak azt az adatot kell beleírni, amit tesztelünk (esetünkben a customer name tulajdonságát), és pl. a company mezőt nem, mégha elvileg foreign key lenne is rá. Persze ez azt is jelenti, hogy a constraint-eket ilyenkor nem teszteljük.
(Megadhatjuk azonban azt is, hogy a constraintek maradjanak).

ejb3
Ez a harmadik modul amit használunk, saját fejlesztés (nagyon egyszerű új modulokkal kiegészíteni a Unitils-t). Ha talál egy @EJB annotacíót a unit tesztünkbe, akkor oda injektálja az EJB-t, és az EJB-be is ellenőrzi az annotációkat és oda is injektál mindent (pl. EntityManager). Nagyon kényelmes, mert gyakorlatilag az egész EJB oldalt standalone unit tesztekkel tudjuk tesztelni. Ha igény van rá, talán majd publikáljuk is.

Ezenkívül van még Spring, Hibernate és EasyMock-ot támogató modulja is, azokat mi nem használtuk. Viszont standalone alkalmazáshoz is viszonylag kis fájdalommal hozzá lehetett gyógyítani (egy migráló szkript használja a Unitils database modulját arra, hogy ő is mindig az aktuális adatbázis sémán dolgozzon). A forrása is szép, mindenütt interface-k vannak, sok helyen lehet változtatni az implementációt.

Nyilván ezzel is előfordulnak szívások, de összességében csak ajánlani tudom. Használata Junit 4.4-től csak annyi, hogy a tesztet meg kell annotálni egy @RunWith(UnitilsJUnit4TestClassRunner.class) annotációval.

Java 7 újdonság szavazás

2007-12-16T13:06:00.000+01:00

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

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

JSPWiki

2007-12-13T17:38:00.000+01:00

Vegyesek az érzéseim:

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

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

GWT widget library

2007-12-06T10:27:00.000+01:00

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

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

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

Java Café I.

2007-11-30T18:12:00.000+01:00

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

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

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

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

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

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

Highlight autoboxing

2007-11-28T17:18:00.000+01:00

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

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

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

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

ProGuard

2007-11-19T00:29:00.000+01:00

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

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

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

Android a házban

2007-11-12T19:44:00.000+01:00

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

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

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

Elhavazva (TopLink kapcsolók)

2007-11-05T15:19:00.000+01:00

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

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

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

NetBeans Feature Request

2007-10-09T15:27:00.000+02:00

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

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

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

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

Glassfish + PHP

2007-10-03T14:59:00.000+02:00

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

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

Deployment Toolkit

2007-10-02T10:48:00.000+02:00

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

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

Itt pl. megmondom neked a JRE verziódat.

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

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

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

Verzió kontroll

2007-09-30T20:19:00.000+02:00

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

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

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

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

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

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

SJSWS => Glassfish 2

2007-09-28T11:11:00.000+02:00

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

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

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

Deployer role

2007-09-24T19:02:00.000+02:00

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

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

Így megy ez.

Wicket nyűgök

2007-09-19T12:42:00.001+02:00

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

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

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

Szép URL-ek

2007-09-17T19:19:00.000+02:00

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

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

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

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

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

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

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

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

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

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

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

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

SCEA Beta

2007-08-30T11:33:00.000+02:00

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

Jazoon fóliák

2007-08-29T18:54:00.000+02:00

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

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

Vissza a gyalupadhoz

2007-08-27T19:36:00.000+02:00

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

TODO list őszre:

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

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

messze.net

2007-08-01T20:45:00.000+02:00

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

Mine metsa. Menj erdőbe.

Java Content Repository Browser

2007-07-17T22:34:00.000+02:00

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

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

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

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

Széljegyzetek process killezéshez

2007-07-16T17:46:00.000+02:00

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

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

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

Java User Meetings II.

2007-07-13T11:28:00.000+02:00

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

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

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

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

Száz

2007-07-11T13:02:00.000+02:00

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

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

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

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

AntUnit

2007-07-09T11:46:00.001+02:00

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

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

  </target>

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

  </target>

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

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

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

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

OSGi server-side

2007-07-05T17:36:00.000+02:00

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

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

A dolog nagyon egyszerű:

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

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

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

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

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

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

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

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

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

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

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

Summary: TheServerSide Java Symposium Barcelona 2007

2007-06-29T23:23:00.000+02:00

Osszefoglalasul:

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

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

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

A TOP5 eloadas nalam:

Jevgeni Kabanov: Aranea-rol
Stephene Colebourne: Java Closures
Ola Bini: JRuby
Alexander Popescu: JCR
Cliff Click: Java Performance Myths

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

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

DAY 3: TheServerSide Java Symposium Barcelona 2007

2007-06-29T22:50:00.000+02:00

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

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

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

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

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

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

DAY 2: TheServerSide Java Symposium Barcelona 2007

2007-06-28T22:41:00.000+02:00

Mielott teljesen elaludnek a gep elott egy gyors vazlat:

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

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

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

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

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

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

Es innentol BOF sessionok kovetkeznek:

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

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

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

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

Holnap utso nap.

DAY 1: TheServerSide Java Symposium Barcelona 2007

2007-06-27T20:35:00.000+02:00

Akkor nezzuk:

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

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

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

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

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

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

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

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

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

TSSJS

2007-06-22T21:27:00.000+02:00

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

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

DOM, SAX, StAX

2007-06-14T10:50:00.000+02:00

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

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

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

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

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

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

SCA vs. JBI

2007-06-05T18:11:00.000+02:00

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

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

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

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

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

Java előadások

2007-06-02T11:25:00.000+02:00

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

http://parleys.com

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

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

JBI I.

2007-05-30T18:01:00.001+02:00

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

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

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

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

JavaOne fóliák

2007-05-25T10:34:00.000+02:00

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

Sun fejlesztő konferencia

2007-05-24T17:39:00.000+02:00

Na akkor lássuk:

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

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

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

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

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

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

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

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

OpenESB I.

2007-05-23T17:18:00.001+02:00

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

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

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

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

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

JSF 2.0 Mit vennél bele?

2007-05-22T11:08:00.000+02:00

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

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

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

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

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

EP function

2007-05-16T16:21:00.000+02:00

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

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

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

Ti tényleg ismertétek?

NetBeans profiler

2007-05-15T21:32:00.000+02:00

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

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

Kissebb problémák voltak:

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

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

Rögvalóság

2007-05-14T14:56:00.000+02:00

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

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

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

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

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

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

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

JUM 1.

2007-05-09T14:38:00.000+02:00

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

2007-05-07T23:19:00.000+02:00

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

2007-05-05T14:06:00.000+02:00

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

2007-05-04T09:44:00.000+02:00

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

2007-05-03T13:32:00.000+02:00

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

2007-05-02T17:14:00.000+02:00

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

2007-04-20T21:43:00.000+02:00

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

2007-04-18T11:43:00.000+02:00

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

2007-04-16T22:56:00.000+02:00

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 ~~jMaki~~jMonkey 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

2007-04-15T22:59:00.000+02:00

(É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

2007-04-09T23:34:00.000+02:00

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.

2007-04-06T10:23:00.000+02:00

Ö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

2007-04-03T19:09:00.001+02:00

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

2007-04-01T18:22:00.000+02:00

((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

2007-03-31T08:59:00.000+02:00

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

2007-03-28T09:37:00.000+02:00

"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?

2007-03-22T18:17:00.000+01:00

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

2007-03-21T09:33:00.000+01:00

Á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

2007-03-20T12:29:00.000+01:00

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

2007-03-13T17:00:00.001+01:00

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

2007-03-09T17:29:00.000+01:00

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

2007-03-06T09:48:00.000+01:00

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

2007-03-03T18:54:00.000+01:00

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

Yadis

2007-03-01T15:16:00.000+01:00

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

2007-02-26T17:35:00.000+01:00

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

2007-02-23T10:34:00.000+01:00

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.

2007-02-21T16:41:00.000+01:00

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.

2007-02-20T14:47:00.000+01:00

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

2007-02-19T17:21:00.000+01:00

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?

2007-02-12T17:53:00.000+01:00

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?