Régi idők

Az egész utóbbi héten Struts-oltam. A régi Strus-cal. Mentségemre legyen szólva, hogy kényszerítettek, annak ellenére, hogy az önéletrajzomban felvételnél feltünően a Spring szerepelt a Struts helyett...

De nem is erről akartam beszélni, hanem hogy egy jó JSF-es alap tudással a Struts mennyire nem okozott meglepetést. Azt szokták mondani, hogy a JSF-et a Struts-on keresztül lehet eladni, mert az egyik specifikálója az a Craig McClanahan, aki a Strutsért is felelős.

Én azonban pont fordítva közelítettem, és ez se volt kevésbé izgalmas. Ismertem a JSF-et, és ez alapján a Strutsba nagyon könnyen el lehetett tájékozódni. Meg tippeltem, hogy minek hol kell lennie, és ott volt. Hiába, nagyon ugyanaz a kettő gondolkodása. Van bennük nagyon sok érdekes dolog, de azért az is érezhető, hogy mennyire távol áll az egész felfogás a Springtől. (Ellentétben a Spring-ből én személy szerint azt értem, hogy jó, hogy van egy elképzelésük az ideális felépítésről , de szinte mindent konkurencuát kipróbáltak, és mindennel össze passzintható.)

RSS reader & writer

Csak hogy ne mindig fanyalogjak: a ROME ügyes kis RSS/Atom olvasó/író. Igaz, hogy elég szimpla API (nem hasonlítható össze mondjuk egy complex webes security rendszerrel), de az nagyon szépen megcsinálva, és nagyon jól ledokumentálva. (pl. ilyen szép színes ábrák, meg persze elegendő példa). Szinte minden formátumot megesik, és lehet még plusz csatolmányokhoz is plugineket berhelni hozzá.

EBJ3 speckó anomália

Kedves esti olvasmányom (core változat innen).

Hanem valaki igazán megmondhatná, hogy hogyan kell ezt a két mondatot egymás mellett értemezni:

"Note that a container can also invoke the PreDestroy method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired. " (4.4 page 76 utsó bekezdés közepe-vége)

"The following scenarios result in the PreDestroy lifecycle callback interceptor method(s) not being called for an instance:

[...]

A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB container implementation-specific way." (4.4.3 page 81 alja - 82 teteje)

Most hogy nagyon töröm a fejem, esetleg arra gondolna, hogy method ready állapotból PreDestroy-jal timeout-tol, passive-ból meg anélkül? De azt azért ennél egyértelműbben is meg lehetne fogalmazni. Talán egy következő fejezetből kiderül. Ötlet?

XSLT vs. Java

Azt hiszem már írtam arról, hogy miért vagyok XSLT ellenes. Már már programnyelv bonyolultságú, de komolyabb dolgokhoz kevés benne a lehetőség. Nem is szólva, ha az egészet Java-ban írnánk meg, akkor mennyivel több funkciót használhatnánk átalakításkor (pl. adatbázis elérés).
(És akor nem beszéltünk a tesztelésről.)

Most olvasomtam itt: Simple Xalan excension function, hogy ez másnak is hiányzik: Xalan-ból kis namespace trükközéssel meg lehet hívni bármilyen Java függvényt. Persze innentől kezdve Xalan specifikus lesz az XSLT-nk.

Úgyhogy akkor én már inkább maradok a dom4-jnél, ahol egy az egyben lekódolták az XSLT algoritmusát Javaban, és egy egyszerű apin keresztül lehet XPath alapú rule-okat mondani. Jelentem használom és működik.

Glassfish + PHP + Drupal

Hogy miért? pl. legacy php-s alkalmazásunk is van, de szeretnénk melette ugyanazon a szerveren (és lehetőleg ugyanúgy 80-as porton) a java-s örömöket is futtatni.

A helyzet nem túl bonyolult még glassfish-ben sem, ahogyan ebben fórumban is írják. Le kell tölteni PHP/Java Bridge binárisát (war file). Kísérlet képpen deployolhatjuk is rögtön, és (nekem a JSF integráció kivételével) rögtön ment is minden demo szépen (session megosztás, php-ból java hívás, stb.).

Saját webalkalmazás sem volt bonyolultabb. Kísérletképpen, hogy egy echo "asd"; nél bonyolultabb alkalmazást vegyek a Drupal rendszert akartam látni működni.

1. Csináltam egy web alkalmazást
2. a JavaBridge.war-ból átmásoltam a web.xml-t (lényege, hogy a *.php-re a saját szervletét meppeli be).
3. a /WEB-INF/lib-ből a php-servlet.jar és a JavaBridge.jar-t hoztam át
4. feltelepítettem a php5-cgi csomagot (demo deployolásakor még nem volt fent! mivel a demo önmagában tartalmaz a WEB-INF/cgi-ben php binárist is)
5. bele a gyökérbe a php fájlokat
6. deploy, és minden szép

Persze még lehetne további dolgokkal kísérletezni. A szemem sarkából láttam, hogy elég komolyan lehet egymásba integrálni a kettőt (pl. az egyik demo java-s excell api-t használt php-ből.) Meg ki kéne valahogy mérni a sebességet is.

De kezdetnek elég lesz ez: könnyű sikerélmény.