Annotation hell

Gyorsan még az is eszembe jutott, hogy elmagyarázzam, miért gondolom azt, hogy az annotációkkal átestünk a ló túloldalára. Úgyis mindjárt reggel van, már jár a villamos.

A nagy XML konfigurációk helyett csodálatos dolog annotációt használni, amikor úgyis csak az az egy konfiguráció lett volna értelmes. Például JPA és más ORM annotációk. Még soha olyat nem láttam, hogy meggondolod magad és nem jó az a név annak a táblának. Kutyát nem érdekelnek a táblák nevei. Persze konkrétan a JPA lehetőséget ad arra, hogy felülbíráld XML konfigurációval az annotációkat.
Hasonlóan lelkesedek azokért az egyszerűsítésekért, amiket a JSR-181 REST annotációk, a JAXB annotációk ésatöbbi hoztak. Az így felannotált osztályokat és interfaceket az ember tipikusan egy pacakge-be dobálja. Igen, helyenként kicsit cifrán néznek ki az osztály-, metódus- és paraméterannotációk. Sebaj, az XML se lett volna kevesebb.

A másik esetben pont a szétszórtsággal van a probléma. Például a non intrusive IoC-nek pont az volt az előnye, hogy nem összeintegrált komponenseket gyártsunk, elég ha POJO, ennek megfelelően tradícionálisan szét lettek szórva a service osztályok, és nincs is nagyon remény a rendszerezésükre. Szóval ezért nem szeretem az annotált IoC-t, beleértve a spring annotációkat is, és tartok tőle hamarosan a servlet 3.0 annotációival is lesz problémám. Képzeld el így a problémát: átveszel valakitől egy spring annotált projektet, nem a dokumnetációtól működik a szoftver tehát dokumentáció nincs, a fejlesztőtől se várhatsz segítséget. Melyik projectet látod át hamarabb? Szerintem az XML-hell egy-két helyen jobb abból a szempontból ott legalább minden egy helyen van. Nyilván ettől lett hosszú. Attól, hogy szétkentük az XML file tartalmát csillió osztályba, attól nem lett se kevesebb, se átláthatóbb, csak az XML lett rövidebb. Sovány vígasz.

Log

Ismétlés a tudásnak azannnya. Péntek délután az Egér Miklós Vasművekben beszámolót tartottam a websüketes túrkálásaimról és a servlet 3.0-ról. Nem sok új ahhoz képest amit már egyébként itt is leírtam pár postban és ott is elmondtam:

1. A Servlet 3.0 zseniális lépés a java szerver oldali technológiában. Na jó ez kicsit túlzás, de végre egy nagyon lényeges újdonság, ami komolyan növeli a java szerverek teherbírását azáltal, hogy egy hosszú és esetleg nem igazán CPU igényes kiszolgálásnak nem kell feltétlenül külön szálat fentartani. Adatbázis műveletek, JMS üzenetre várakozás, de például akár várakozás más erőforrásokra is, pl gondolom nem igazán szeretnél szerver oldalon párhuzamosan 10 db jóminőségű hubble űrteleszkóp képet feldolgozni kicsi heap memóriával. Ugye...
2. A Servlet 3.0 kifejezetten olyan dolgokra nagyon alkalmas, mint a long poll. Amit ugyebár a szerver push-kén használunk.
3. A Websocket API, ami már ott van a firefox 4-ben, chrome 7, IE 9 (jajj hát ki legyen mindig a legutolsó) satöbbi, szóval ez az API lehetővé teszi, hogy TCP socket-szerű tartós kapcsolatot építsünk fel a kliens és a http szerver között.
4. A Websocket API ha egyszer elterjed, komoly átalakítsok vállnak kézenfekvővé a szoftverfejlesztésben. Szerintem a legtöbb esetben maradnak a régi ajax hívások is, de jópár esetben a websocket le fogja helyettesíteni. A long poll biztos hogy menni fog.
5. Ennél vlószinűleg lényegesebb kihívásokkal kell az üzemeltetés terén szembenézni. A Websocket ugyebár HTTP 101 "Switching Protocol" státusszal kezdődik és innentől az egész kommunikáció nagyon más, mint egy szokásos HTTP kapcsolat során. Kell számítani nehézségekre a proxykon, load ballancereken, stb. Azóta kipróbáltam, hogy apache mod_proxy korrekten kezeli-e ezt a protokolt, de nem ment vele. Aztán lehet az apacs mágusok életre tudják kelteni, de nekem nem ment. Még ki kell próbálnom mod_ajp-vel is, valamiért én inkáb azt használom ha muszáj, nekem az egyszerűbb.
   Viszont a másik kérdés: akarunk apacsot az egész elé? Amikor az kapcsolatonként 1 processzt de legalábbis egy szálat visz, míg a java szerver oldalon már nincs erre szükségünk? Lehet a httpd bottleneck lesz az architektúrában? Illetve most még nem az?
6. Még mindig kérdés, hogy szükség lesz-e a websocket témogatásához valami külön servlet engine kiegészítéshez, vagy belefér-e a sima servlet API-ba. Szerintem kifejezetten jobb lenne, ha a servlet API fürgén előjönne valami támogatással, én mindenesetre a jetty saját apiját használom. Ebből következőleg a kód nem fut pl tomcaten.
7. Ilyen módon mire tényleg használatba vesszük a Servlet 3.0 API-t, talán már nem is lesz rá szükségünk sokáig. Ugyanakkor az, hogy nem tartunk külön szálat minden kliens kapcsolatnak, még inkáb fontos lesz ha majd egyszer Websocket klienseket szolgálunk ki.
8. Ezzel kapcsolatban kicsit szorgoskodtam és dolgozok még mindig egy olyan prototipuson, ami a kliens elől eltakarja hogy long-pollt vagy websocket-et használ. Ennek egy működőképes változata itten-e van. Próbáljátok ki: svn co után mvn jetty:run. Ez a prototipus egyébként egy kicsit elvetemültebb koncepció és télleg csak kisérleti jellegű. Ha egyszer megnő, akkor meg fog érdemelni egy magyarázatot itt, addig még kalapálom és dumálunk róla.

Szóval mindez még nagyon messze van az éles bevetéstől.

Sonar eclipse plugin (FYI)

András hívta fel a figyelmem erre a pluginra, igazi frankó cucc :-) Amúgy nem szeretem pluginekkel telezsúfolni az eclipse-t, stabilabb biztosan nem lesz tőle, de ez egy értelmes ötlet: ahol hegesztek, ott nézhetem a hegesztés minőségét is és javíthatok rajta.

Király lenne az open source projectjeimhez egy sonar valahol, otthon is jó lenne bevetni. Az anzix.net-en ment egy, de eltünt.

Valamint még azt akartam kérni, hogy aki ott van a JUM-on, az légyszi írjon már beszámolót, lehetőleg minnél többen. Én még mindig melóban. Köszi...