Apache ftpserver próbakör...

Elösször is szerintem az FTP filetransfer-es rendszerintegráció egy agyhalál, idejétmúlt, matuzsálem, őskövület, stb, de úgy tünik távoli munkatársaim egész hadai nem értenek ezzel egyet, és miután beláttam, hogy nem tudom másra rávenni őket, eltöltöttem egy kis időt káromkodással persze, aztán lekódoltam a cuccot és oda jutottam, hogy unit tesztel kellene körbetámasztgatni a dolgot. Jobb későn, mint soha :-)
És hamár unit-tesztelünk, de szép lenne ezt az egészet úgy csinálni, hogy ne kelljen neki valami ftp szerver valahol, felhasználóval, satöbbi, hanem ahogy van a project kicheckoutolás után már úgy magában is le tudja tesztelni önmagát. Arra gondoltam, hogy az ftp file-transzert kezelő kód teszteléséhez felstartolok egy beágyazott FTP servert, konkrétan a nemrég megjelent, MINA alapú Apache Ftpserver akadt a kezembe. Igazából az hogy NIO-s az ebben az esetben semmit sem ér, de a virtuális file-rendszere, "ftplet" api... szép kis cucc.

Hmm, hát tényleg beágyazható és nagyon jól megy, de a pársoros kis izé helyett 20-30 sorosra hízott inicializációt kellett írnom hozzá, ami azért szerintem sok egy tesztben. Plusz az enyémhez hozzá kell venni a filerendszer kurkászást és az azonosítási rendszer inicializációját is. Szóval kis egyszerűsítéssel szerintem jó fájdalomcsillapító lehetne.

Agyhalott AOP svájcibicska

Pár AOP-os cuccom mostanában, ami szerintem egy jól működő rendszerben nem, vagy csak ritkán tudnék elképzelni...

• Cache interceptor: főleg távoli metódushívások elé. Ez talán még nem olyan vészes. Egy akármilyen jcache megteszi neki, vagy egy map is. Újabban adatbázisba perzisztált map-en kisérletezek, annyi adatot kell cachelni és a backend olyan gyenge, hogy a memória + frissítgetés nem lenne jó megoldás.
  Ennek még látném valami hasznát egyébként, de azért érdemes odafigyelni a példaértékűen halott spring-modules cache projectjére.
  
• Timeout intercetor: ha a metódus nem tér vissza X idő alatt (lassú backend), akkor hagyja futni és egy bekonfigurált értéket ad vissza helyette, vagy hibát. Ezt nyilván úgy csinálja, hogy külön szálat indít neki.
  
• re-try interceptor: Szerintem ez a legbetegebb :) Van pár dolog, ami elsőre néha nem sikerül, és ilyenkor simán lehet hogy másodszorra vagy harmadszorra igen. Talán. Szerintem ez botrány, de ez van. Ez az interceptor elkap bizonyos bekonfigurált hibákat és újrapróbálja a hívást. Például egy bankkártya művelet tipikus példa arra, hogy hol nem merném bevetni :-) Persze azok is besz@rnak hébe-hóba.
  
• Logging interceptor: a lassan válaszoló hívásokat logolja. Nem mintha utánna tudnék javítani a lassú backendeken...

Ez így egy április elsejei bejegyzésnek is elment volna, de nem az :-)