Time out

Semmi gőzölgő kávé, semmi forróság. Elmentünk északra. Augusztus végén jövünk.

Liferay ismerkedés

Szóval keresek egy portálrendszert, ami: ingyenes, moduláris, könnyen bővíthető, viszonylag vállalható architektúrájú.

Ennek keretében nyomogattam egy kicsit a Liferay-t. Első tapasztalatok.

1. Nem tudom miért, de ezzel is az az érzésem, hogy fejlesztők azt mondják, hogy jó jó az OS, de a dokumentációt nem visszük túlzásba, hogy a supportba visszacsöpögjön valami. Mert vagy én vagyok nagyon hülye, vagy tényleg egy kicsit kevés a dokumentáció.

Senki nem szólt pl. hogy linux alatt léteznie kell egy /home/liferay-nek, ahová tudjon írni a portál, különben exception-ökkel elszáll.

(Külön izgalmas, hogy ha dokumentációt keresek az oldalon, akkor azzal kell szembesülnöm, hogy én nem felhasználó vagyok, hanem developer. A developer zone alatt vannak a doksik, és a developer doc tartalmaz egy sokkal részletesebb install leírást, mint az user guide.)

2. Ami izgalmas volt számomra, az a portlet alapú működés. Eddig is tudtam a portletekről, de még sose láttam a gyakorlatban, hogy hogy megy. A Liferay nagyon szép példa volt. Teljesen más gondolkodás mód mint amit megszoktam. A kis CMS-ek általában úgy működnek, hogy van egy url, és az alatt egy funkció (hírek, képgaléria, stb.). És ha nagyon kell, akkor blokkokat nyomhatok a fő tartalmak köré. (Szerencsés esetben megadhatom, hogy a blokkok mikor ne, illetve mikor látszódjanak).

Itt teljesen máshogy van. Van egy url, és az egy tiszta lap. Ebbe dobálhatom bele a portleteket (blokkokat). Mindegyik lapra külön beállíthatom, hány hasábos legyen, és hogy portleteket dobálok bele, vagy mondjuk IFRAME-es legyen.

A portleteket külön lehet konfigurálni, viszont ha egy oldal egyik portletjének egy aloldalára szeretnék menni, akkor az teljes képbe bejön, és eltűnik minden más az oldalról, pedig lehet, hogy néhány blokkot én továbbra is láttatni szeretnék.

3. A Liferay4.0-val szállított portletek szerintem elég halványak. Pl. az Image galery elég szánalmas. Ezért inkább egy jó keretrendszernek tűnik (legalábbis azt nem néztem) de a hozzáadott dolgok egy kicsit fapadosak, kevés dolgot lehet konfigurálni rajtuk.

4. Néhány megjegyzés még:

• My places alá helyet új community felvételével lehet csinálni.
• Ha utáljuk az alap demó adatbázist, akkor első körben a web.inf-ben kell a company_id-t megváltoztatni. (Gondolom az adatbázisban a sok szemét még megmarad, de legalább üresen lehet tesztelni.)
• Az többnyelvű tartalmakat nem tudom elérni, mert amit a csilli villi lifecat tutorial mutat, az az üres adatbázisban nálam nem elérhető, és a doksi mélyen hallgat, hogy hogy kell bekapcsolni.
• Azt hogy egy oldal hány oszlopos legye, az új portletet hozzáadó oldalsávban lehet beállítani.

Maven kezdet

Valószínű már mindenki Maven2-n nyomja (az egészen ortodox ant hívőket kivéve), meg kellett hát néznem nekem is. Egy kis projektem migrálásával próbáltam ki.

Útmutatóm a nagyon korrekt (regisztráció után ingyenes letölthető) Better Builds with Maven könyv volt. (Az első fejezeteit olvastam el eddig, az alapokat nagyon korrektül leírja).

A vélemények:

1. a plugin rendszer, a közös repo, amiben a függőségeket tárolja az első használat után is igen meggyőző megoldás.
2. az alap pluginek a leírás alapján nagyon könnyen beizzíthatóak voltak, ment minden pöccre.
3. illetve néha kiírta, hogy valamilyen függőséget nem talál, de ha mégegyszer elindítottam, akkor simán letöltötte. Utána meg már ment, úgy hogy nem volt kedvem utánamenni mit nem állítottam be.
4. Azért az alap pluginek között is van néhány rejtély. Pl. az scm (amiről a könyv nem beszélt részletesen csak a release fejezet révén egy kicsit és ott még nem tartok). A generált honlapja pl. tartogat néhány 404-et, és a jirában 2004 óta terveztgezik, hogy Create user guide/Guide for the impatient programmer
5. Azért én türelmes voltam és kiderült, hogy viszonylag kis munkával, ha nincsenek is a goal-ok kiírva a plugin lapján a forráskódból kideríthető a működés.
6. A pluginek doksija általában néhány példa, ami sokszor elég, néha nem. Nagyon sokat lehet tanulni azonban a forrásukból is, mert általában a pom.xml (és pl. a site source) is fent van a verzókövetőben és rögtön lehet látni, hogy hogy csinálták meg ők valamit.
7. Persze az alap pluginek működése közül sok nem azt nyújtja pontosan amit én szereték (pl. changes), de azt látom, hogy nagy királyság az is, ha ilyenkor írok egy plugint és egy életre meg lesz ami kell.
8. Azért nagy és bonyolult projekteknél a site generátor nem tudom mennyire működne, de szinte megjött a kedvem a kis lokális projekteket is egy hejde kis maven site-tal dokumentálni.
9. Alig várom, hogy az sf plugint is kipróbáljam, mert ha az is megy, akkor tényleg befizetek rá.

Hessian

Kb. 1.5 hete babráltam vele egy kicsit, úgy hogy gyorsan leírom a tapasztalataimat, amíg el nem felejtem.

Előszőr is (tudom unalmas): dokumantáció. Én se vagyok egy nagy bajnok benne, de az hogy a http://www.caucho.com/hessian/ oldalon a JavaDoc menü alatt nem a legfrissebb verzió (2005/05/16 3.0.13) javadocja van kigenerálva, az szerintem elég átverés (én meg naívul onnan kezdtem el böngészni, és csodálkoztam, hogy a forrással nem klappol.)

A másik az volt, hogy nekem még mindig túl sok adat ment át a hálózaton. Ez főleg azért történt, mert a protokol az objektumokat ugyanúgy kezelte mint a Map-et, azaz kulcs érték párokat írt le, és ha én 1000 objektumot (mondjuk egy List-be rakva) leszerializálok, akkor 1000-szer benne lesz a kódolt üzenetben az összes osztályváltozóm neve. (Ez még teljesen korrekt, egy protokolt valahogy definiálni kell.)

Sebaj gondoltam, majd szépen átírjuk a szerializáló függényt. Azt hogy melyik objektumra milyen szerializáló algoritmust használunk a SerializerFactory adja meg. (byte-tól kedzve char[]-ig mindenre szépen külön megadja, hogy ki fogja szerializálni). Gondoltam szépen származtatok belőle egy sajátot, és ott átírom az Object[] szérializátorát. Ekkor jött a meglepetés: az alap szerializátorokat egy static{} (!) blokkban állítja be az osztály (a getSerializer függvény nem static). Biztos volt oka, hogy miért nem a konstruktorba került, végül is csak futólag néztem meg, de ez futólag nézve nekem elég gyanúsnak tűnt.

((A megoldás egyébként az lett volna, hogy csinálok egy üres SerializerFactory-t, ami csak az én konkrét osztályaimra ad vissza szerializátort, és ezt egy alfactoryként hozzá lehet adni a főhöz. De pl. az Object szerializátorát globálisan nem tudtam megváltoztatni.)) Végül egy rövid teszt program (csak hogy itt legyen nekem) hogy hogyan teszteltem, hogy mekkora lesz egy objektum szerializálója (a service POST-okat használ, azt nem volt kedvem birizgálni) Object test = new TestOne(); OutputStream os = new FileOutputStream("test.bin"); HessianOutput out = new HessianOutput(); SerializerFactory factory = new SerializerFactory(); out.setSerializerFactory(factory); out.init(os); out.writeObject(test); os.close();

Spring plugin framework

Régóta foglalkoztat a kérdése, hogy hogy lehet a Spring frameworkből (j2ee használat esetén) valami modulláris-pluginos cuccot csinálni. (Mondjuk mint a JPF, aminek meg az Eclipse a mintája).

Most a TSS linkelt be egy cikket. Ami lightweight pluginekről beszél spring alatt.

A tehcnika röviden:

class betöltés: j2ee esetén azt tanácsolja, hogy dobjunk be mindent a WEB-INF/lib-be, és akkor nem kell velel foglalkozni, hogy mi töltődik be. Standalone app esetén egy ant build fájlt használ indításra. Az ant classpath megadásánál ugyanis lehet * wildcardot használni.

A j2ee-s változattal csupán az a bajom, hogy a modulr kódja és a függőségei összekeverednek egymással. Ha egy-egy modulomnak 5-10 jar függősége van, akkor nehéz lesz kihámozni a lib könyvtárból, hogy mi a függőség, és mi a modul.

Viszont az kétségkívül előnye, hogy könnyen meg lehet emiatt oldani a több modul -- ugyanaz a függőség problémát. Lehet hogy valami fájlleíróval a függőségeket is szimpla modulként kéne kezelni.

spring bean építés: a bean-ek külön fájlokba helyezése sose volt probléma. A Spring remekül támogatja, hogy ne egy bean fájlt, hanem sok kicsit olvasson be.

hook rendszer: A kiterjeszthetőség elég izgalmas: Hook meghirdetése gyakorlatilag egy szimpla bean-nel történik, aminek a List típusú paramétereit üresen hagyja. Hook regisztrálása egy BeanFactoryPostProcessor leszármazottal történik (emiatt az xml-el feldolgozása után, de a bean-ek létrehozása előtt kerülnek ezek a beanek meghívásra). És ezeknek a bean-eknek a konstruktorába szépen a meghirdetett beanek üres paramétereit kitölti a saját praméterei alapján. (Nem tudom nem gáz-e, hogy ha sok ilyen kiterjesztést akarunk regisztrálni, akkor tele leszünk, felesleges objektumokkal a memóriában. EZek az objektumok csak regisztráláskor fontosak).

A TSS cikke után viszont izgalmas hozzászólások vannak, egyéb megoldásokra.Eddig csak az el4j-t néztem. Lehet hogy én vagyok nagyon nehéz felfogású, de én még egy kicsit több doksira, és step-by-step tutorialokra vágynám, hogy teljesen átlássam a dolgokat.

Tomcat Xen memory test folyt.

A dolog most így áll: a szerveren postgresql 8.1, tomcat 5.5 és egy alap spring framework alapú AJAX-os j2ee alkalmazás. (Meg presze munin-node, amivel a grafikont csináltam). Úgy tűnik ennyi még éppen belefér a 128 megába. (a zöld, amit használok, a cache-t, ha jól tudom, még fel tudnám használni)

UPDATE: úgy tűnik hosszú távons is bírja. Amióta 128-on megy, még nem volt oom killer.

Tomcat Xen alatt memory test

Szóval mennyi memória kell egy xen dom1-nek, ha tomcat-et akarok futtatni rajta. A dolog egyszerű:

1. default ubuntu dapper debootstrap
2. apt-get install sun-java5-jdk
3. wget tomcat 5.5, tar xvzf
4. startup.sh

Egyelőre nézzük az alap telepítést, különösebb app nélkül: 128 memória alatt simán ment. Lemegyek 48-ra: az is megy.

Ez azért érdekes, mert a budget dedicated hasonló cucca 48 memórával meghallt. Úgyértem el se indult.

Most 48-ccal simán megy, de annyira nem szép a helyzte, mert az oom killer rendszeresen kilövi a tomcat-et memória hiánykor. Vissza 128-ra.