(Épp valami zizi van a gépemmel, és addig köhögni sem merek, amíg bootcdről indulva le nem szinkronizál a home partíciom raid1-ben. Az után jöhet a hibakeresés.
A Knoppix bootcdn meg nincs java. Pedig kéne.)
Szóval addig sztori:
A múltkoriban meglátogattuk a gyárat, ahol a cég szoftvere élesben fut (régi c-s cucc, majd javaban újraírjuk.). Érdekes volt látni. Ülnek az operátorok, az egyik monitorban az egyik rendszer, a másik monitoron a másik rendszer, és még egy ablakban a harmadik. Átjárás korlátozottan. Azt hiszem kezdem érteni, miért lett most a SOA olyan nagy divatszó.
A legjobb viszont, hogy az egyik kopott konzolos alkalmazás még egy 286-oson futott. Arra fejlesztették, és azóta megy szépen, pont annyit tud, amit kell. Az egy kérdés, hogy ha elfüstöl benne valami honnan szereznek hozzá alkatrészt. De azt is megnézném, hogy hogyan integrálná a cuccot bárki is.
2007/01/29
2007/01/26
soros port II.
Na, azért csak meg kell védenem a Sun-t. Ugyanis az RxTx windowson ilyen zamatos hibaüzenettel szál el:
A régi Javacomm API val, meg azért megy minden rendben.
AZért felemelő ez, amikor a linux alá minden van, és Windows-os kompatibilitással kell bütykölni :-)
An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION(Bár furcsa, mert az egyik eszközömmel simán megy, csak a másik akad ki. HyperTerminállal mind2ő szépen pörög.)
A régi Javacomm API val, meg azért megy minden rendben.
AZért felemelő ez, amikor a linux alá minden van, és Windows-os kompatibilitással kell bütykölni :-)
soros port
Soros portot szernék használni. Lehetőségek:
Java Communications API
Sun-os megoldás, (bár ha jól látom nincs rá JSR, ez csak egy megvalósítás). A 3-as változat csak linuxot és Solarist támogat, a 2-es változatot elvileg előbányászható, és abban van windows-os is.
RxTx
Mindent eszik: MaxOSX, Linux, Windows, BSD, stb. Nálam egyértelműen ez a nyerő.
CDC
PocketPC-re elvileg a CDC-be kell lennie.
Az SMSlib (soros porton SMS-eket olvasó API) pl. a sunossal és az rxtx-el is megy. Csupán ANT fordítás előtt ki kell cserléni egy class elején az import javax.comm-ot gnu.io.*-ra. Vicces megoldás.
Java Communications API
Sun-os megoldás, (bár ha jól látom nincs rá JSR, ez csak egy megvalósítás). A 3-as változat csak linuxot és Solarist támogat, a 2-es változatot elvileg előbányászható, és abban van windows-os is.
RxTx
Mindent eszik: MaxOSX, Linux, Windows, BSD, stb. Nálam egyértelműen ez a nyerő.
CDC
PocketPC-re elvileg a CDC-be kell lennie.
Az SMSlib (soros porton SMS-eket olvasó API) pl. a sunossal és az rxtx-el is megy. Csupán ANT fordítás előtt ki kell cserléni egy class elején az import javax.comm-ot gnu.io.*-ra. Vicces megoldás.
2007/01/24
SWT
Már megint le vagyok maradva a könyveléssel.
Még a hétvégén olvasgattam SWT könyveket, hogy lássam, mit is lehet csinálni vele. Eddig főleg NetBeans (ami ugye Swing) platform környékén jártam, és eddig sikerült elkerülnöm az Eclipse környékét, úgy hogy kicsit kiváncsi is voltam, meg aggódtam is, hogy el fog tartani, amíg egy nagy GUI-t bevágok.
Hát mit mondjak. Valahogy a PHP jutot eszembe. Nyilván a full extrás OOP absztrakciók felől nézve elég szerény a dolog, de az is igaz, hogy az egyszerűségnek is van esztétikája. Nem lehet véletlen, hogy annyi Eclipse plugin van: nyilván a GUI-t is egyszerűbb össze rakni.
Egyelőre nem tudom szeretni fogom-e, ahhoz még konkrét pocket pc-s projektek kellenének, de mindenesetre az SWT-s könyveket hamarább átfutottam, mint hittem.
Még a hétvégén olvasgattam SWT könyveket, hogy lássam, mit is lehet csinálni vele. Eddig főleg NetBeans (ami ugye Swing) platform környékén jártam, és eddig sikerült elkerülnöm az Eclipse környékét, úgy hogy kicsit kiváncsi is voltam, meg aggódtam is, hogy el fog tartani, amíg egy nagy GUI-t bevágok.
Hát mit mondjak. Valahogy a PHP jutot eszembe. Nyilván a full extrás OOP absztrakciók felől nézve elég szerény a dolog, de az is igaz, hogy az egyszerűségnek is van esztétikája. Nem lehet véletlen, hogy annyi Eclipse plugin van: nyilván a GUI-t is egyszerűbb össze rakni.
Egyelőre nem tudom szeretni fogom-e, ahhoz még konkrét pocket pc-s projektek kellenének, de mindenesetre az SWT-s könyveket hamarább átfutottam, mint hittem.
2007/01/22
PDA + Java II.
PDA fronton elértük az első sikereket:
Az AWT el lett doba, helyette SWT. Lejött egy default Eclipse telepítés Visual Editor modullal. (A folyosón azt mondták, hogy bármennyire is Swing pártiak legyünk, PDA-n még igaz (ami PC-n már nem igazán), hogy az SWT gyorsabban fut, úgy hogy mindenképpen használjuk azt).
Az SWT dll-t és jar-t felraktam a PDA-ra a J9 megfelelő könyvtáraiba, és vidáman futnak azóta az SWT-s programok. (A J9-nek van PC-n futtatható változata, oda a PC-s SWT kell, és akkor többé kevésbé a PC-n tesztelhető az alkalmazás.)
A legjobb leírás amit találtam ez, főleg, mert mellékel néhány példa forrást is.
Az AWT el lett doba, helyette SWT. Lejött egy default Eclipse telepítés Visual Editor modullal. (A folyosón azt mondták, hogy bármennyire is Swing pártiak legyünk, PDA-n még igaz (ami PC-n már nem igazán), hogy az SWT gyorsabban fut, úgy hogy mindenképpen használjuk azt).
Az SWT dll-t és jar-t felraktam a PDA-ra a J9 megfelelő könyvtáraiba, és vidáman futnak azóta az SWT-s programok. (A J9-nek van PC-n futtatható változata, oda a PC-s SWT kell, és akkor többé kevésbé a PC-n tesztelhető az alkalmazás.)
A legjobb leírás amit találtam ez, főleg, mert mellékel néhány példa forrást is.
2007/01/18
Service Provider Interface
Eredetlieg azt hittem, hogy legalábis egy kiforrott API, de aztán kiderült, hogy maximum egy tervezési minta.
Arról van szó, hogy van egy alap programunk, és szeretnénk kiterjeszteni a funkcionalitást mindössze annyival, hogy bedobálunk a classpathba jar-okat. A(z egyik lehetséges) megoldás:
Van egy interface, ezzel definiáljuk, a kiterjesztési pontot. A bedobállandó jarokban implementáljuk az interface-t. (Eddig minden a szokásos).
Aztán csinálunk a jarokban egy könyvtárat és abban egy sima szöveges fájlt (mondjuk META-INF/services/com.domain.csodainterface) és egy-egy sorban felsoroljuk az implementáló osztályokat. A főprogram fogja a classLoader-ét és a getResources(META-INF/services/com.domain.csodainterface) metódussal szépen megkapja a fájl referenciákat. Ezekből kiolvassa a sorokat (amikben class nevek van) és ezeket reflection api-val szépen meghívogatja.
Azt hiszem ez csak egy módszer, de meglepően sokat találkozom mostanában vele (pl. Így lehet a radeox wiki engine-be új makrókat definiálni).
Linkek:
Ethan Nicolas vázolja a helyzetet
Jar speckóban emlegetve
Ez utóbbi emlegetés különösen kedves, mert nagy bizonyossággal hivatkozik egy Service.providers funkcióra, amit (ahogy számomra kiderült) nekem kell végül is megírni a fent említett módon.
Arról van szó, hogy van egy alap programunk, és szeretnénk kiterjeszteni a funkcionalitást mindössze annyival, hogy bedobálunk a classpathba jar-okat. A(z egyik lehetséges) megoldás:
Van egy interface, ezzel definiáljuk, a kiterjesztési pontot. A bedobállandó jarokban implementáljuk az interface-t. (Eddig minden a szokásos).
Aztán csinálunk a jarokban egy könyvtárat és abban egy sima szöveges fájlt (mondjuk META-INF/services/com.domain.csodainterface) és egy-egy sorban felsoroljuk az implementáló osztályokat. A főprogram fogja a classLoader-ét és a getResources(META-INF/services/com.domain.csodainterface) metódussal szépen megkapja a fájl referenciákat. Ezekből kiolvassa a sorokat (amikben class nevek van) és ezeket reflection api-val szépen meghívogatja.
Azt hiszem ez csak egy módszer, de meglepően sokat találkozom mostanában vele (pl. Így lehet a radeox wiki engine-be új makrókat definiálni).
Linkek:
Ethan Nicolas vázolja a helyzetet
Jar speckóban emlegetve
Ez utóbbi emlegetés különösen kedves, mert nagy bizonyossággal hivatkozik egy Service.providers funkcióra, amit (ahogy számomra kiderült) nekem kell végül is megírni a fent említett módon.
2007/01/15
PDA + Java I.
(Azt hiszem, kicsit lemaradásban vagyok, most csak a legutóbbi:)
Szeretnék Java programokat írni PDA-ra. A Sun-nak csak egy csomó speckója rá, de VM-je nincs. (A folyosón azt mondják, hogy volt, csak durván összeveszett az MS-sel, és azóta nincs.)
Az egyöntetű vélemény az, hogy J9-et kell használni (vagy ahogy ők mondják: WebSphere Everyplace Micro Environment). Ez elvileg 5$, de le lehet tölteni és ki lehet próbálni ingyen is. Fent is van.
Már csak a fejlesztő eszköz a kérdés. NetBeans-nek van CDC változatú Mobile Pack-je, de az se ilyen egyszerű. Ove Nordström (kimondani is gyönyörűség a nevet) bolgjából azt vélem kiolvasni, hogy két fajta GUI szabvány létezik az aGUI (Swinges, amit a NetBeans CDC tud és jsr, viszont Norström szerint még nem támogatják a készülékek) és az eSWT (az SWT egy részhalmaza és az IBM-ék nyomják). Ez utóbbit le is lehet tölteni és egy dll-el együt felcopyzni, és akkor menne. De ehhez nincs fejlesztő eszközöm.
A folyosón még azt mondták, hogy csináljak sima java projectet és csak az AWT elemeket használjam. Nem tudom ugyan használni a java.micro csomagokat (ami azért kelleni fog előbb utóbb), de menni fog.
Kipróbáltam és nem ment. Egyszerűen lefut a program, és semmit nem jelenít meg. Rejtély.
Tervek:
* hagyni a netbeans-et és keresni olyan Eclipse plugineket, amikkel megy a CDC és SWT csinál, és azt kipróbálni.
* Esetleg kipróbálni az IBM eclipse alapú csodáját (3 hónap trial, utána ~600$)
* törni a fejem, hogy egy awt miért nem indul el simán, és miért nem szól, hogy elszáll.
* keresni néhány mintát
Szeretnék Java programokat írni PDA-ra. A Sun-nak csak egy csomó speckója rá, de VM-je nincs. (A folyosón azt mondják, hogy volt, csak durván összeveszett az MS-sel, és azóta nincs.)
Az egyöntetű vélemény az, hogy J9-et kell használni (vagy ahogy ők mondják: WebSphere Everyplace Micro Environment). Ez elvileg 5$, de le lehet tölteni és ki lehet próbálni ingyen is. Fent is van.
Már csak a fejlesztő eszköz a kérdés. NetBeans-nek van CDC változatú Mobile Pack-je, de az se ilyen egyszerű. Ove Nordström (kimondani is gyönyörűség a nevet) bolgjából azt vélem kiolvasni, hogy két fajta GUI szabvány létezik az aGUI (Swinges, amit a NetBeans CDC tud és jsr, viszont Norström szerint még nem támogatják a készülékek) és az eSWT (az SWT egy részhalmaza és az IBM-ék nyomják). Ez utóbbit le is lehet tölteni és egy dll-el együt felcopyzni, és akkor menne. De ehhez nincs fejlesztő eszközöm.
A folyosón még azt mondták, hogy csináljak sima java projectet és csak az AWT elemeket használjam. Nem tudom ugyan használni a java.micro csomagokat (ami azért kelleni fog előbb utóbb), de menni fog.
Kipróbáltam és nem ment. Egyszerűen lefut a program, és semmit nem jelenít meg. Rejtély.
Tervek:
* hagyni a netbeans-et és keresni olyan Eclipse plugineket, amikkel megy a CDC és SWT csinál, és azt kipróbálni.
* Esetleg kipróbálni az IBM eclipse alapú csodáját (3 hónap trial, utána ~600$)
* törni a fejem, hogy egy awt miért nem indul el simán, és miért nem szól, hogy elszáll.
* keresni néhány mintát
2006/12/22
gosling
Ez a gosling nem az a gosling. Ez egy ant átirat, amit az ant fájlokat használja, de nem xml-ben kell build fájlt csinálni, hanem Javaban. (Érdemes megnézni a példát.)
Egyrészt engem meg lehet győzni. Miért is ragaszkodunk mindig annyira az XML-hez, ha egyszer a kedvenc nyelvünk sokkal intelingensebb nála? A TSS-en épp a minap fanyalogtak az 1.7-es ant kiadásával kapcsolatban, hogy exception kezelés meg if/while elemek mennyire hiányoznak az ANT-ból.
Másrészt, engem mindenről meg lehet győzni, de mindenről csak akkor, ha együttműködik az IDE-mmel (most épp NetBeans). És lehetőleg ne egy ritkán fejlesztett pluginen keresztül, hanem pl. mint az IvY ANT fájlon keresztül teljesen legyen behegeszthető.
Amúgy már rég akarok írni, hogy azt hiszem az IvY lesz a menekülési útvonal a Maven2 elől. Van a fejemben egy lightweight ant+ivy based build környezet, ami azt hiszem pótolni fogja tudni. Csak kéne rá egy kis idő.
2006/12/18
vision
Spring RCP-hez kerestem tutorialokat a minap, amikor ebbe akadtam bele. Nem csak azért tetszett, mert a Spring RCP közismerten alul dokumentált (viszont elég igéretes ahhoz, hogy ennek ellenére éremes legyen túrni) és egy jó tutorial nagy érték. Hanem mert ez nem is inkább tutorial, hanem inkább olvasó napló. Nem csak azt írja le, hogy hogynan kell életet lehelni a funkciókba, hanem azt is, hogy hogyan jutott el a megoldásra. Hol és hogyan találta meg a szükséges információkat.
Szimpatikus megoldás. Azt hiszem ezek után én is ezt fogom csinálni. Java olvasónapló. Mindennapi problémáim.
2006/12/13
Ajax, Swing, ...
Múltkor az egyik állásinterjún amikor a vezető látta az AJAX szót rögtön az lett a feladat, hogy győzzem meg, hogy miért jó az AJAX, mi többet ad egy Swing alkalmazáshoz képest.
Mondtam neki, hogy rosszul fogja fel a dolgot, épp hogy kárpótol a Desktop alkalmazások feelingjének elvesztése miatt.
Csak arról jutott eszembe, hogy épp egy zseniális webappot csinálunk, illetve annak is most csak a css/js szkript részét. Annó desktop alkalmazás volt, de aztán kitalálták, hogy legyen webes alkalmazás, mert az olyan trendi. (intranetes, tehát kevesen használjk, és simán meg lehetne követelni egy WebStart-ot is a böngészőn kívül.) Meg is épült az első változat, jelenleg a másodikon kell dolgoznom. De ebbe most olyan szép követelmények vannak (itt legyen scroll bar, ott legyen, ezt mutassa, oda popup), hogy egy kicsit kezdek vágyakozni a Swing után. Az legalább egy Java api, és nem kéne itt gányolnom a CSS/JS-t. A böngészőkompatibilitásokról nem is beszélve.
Na megyek is vissza. Köszönöm, hogy elmondhattam.
2006/12/12
jalopy
Kódformázó (éjlenek a céges policyk) aminek utsó release februárban jött ki (1.5rc) miközben a sourceforge-olt oldalról belinkelt cég már 1.7-et is árul. (Vajon a szerzőkre nem vonatkozik a GPL és nem kell kiadni a forráskódot?)
1. Előszőr is kiderült, hogy ha 2 sorba kerül a metódusnév, akkor nekem a kapcsos zárójelet a harmadik sorba kell írnom, és ezt semmiképp nem tudta. Sebaj, nyílt a forrás. Kinyitom, hunyorítok.
Interface-ek csak kevesen inkább közvetlen leszármazottak. (lásd Dependency Inversion Principle) már gyanús, hogy nem lehet szépen cserélgetni amit akarok. És valóban. Viszont a forrásban hamar megtaláltam amit nekem kellett és csak egy helyen írtam át. Nosza repacking és minden megy is szépen ANT taskból. (Elfogott a kísértés, hogy csak az újrafordított osztályt másoljam be a régi jarba, ha már tákolunk, csináljuk durván :-) Szegény ember IoC-ja mondja erre egy koléga.)
2. Persze vérszemet kaptam és kb 10 munkaórában össze is raktam egy NetBeans plugint rá. Ha majd letisztázom valahol publikálni is fogom, ha valakinek nagyon kell írjon a commentbe...
Amúgy már régen kísérleteztem NetBeans platformmal, de most valahogy minden összeállt és kezdtem átlátni a dolgokat. Nem OSGi persze, de azért elég szép komponens alapú, ami nekem alapból megdobogtatja a szívem.
2006/12/11
1.6
Most már két tizedes választja el a jelenlegi project policyt a kurrens verziótól. Remélem nekik is fel tűnik. És legalább az 1.5ig eljutunk.
(A hírben mintha 60 napos ingyenes supportot írtak volna, amit ki kéne próbálni :-)
(A hírben mintha 60 napos ingyenes supportot írtak volna, amit ki kéne próbálni :-)
2006/12/07
2006/12/04
Utóirat
Kedves Jézuska. Szeretném, ha karácsonyra hoznál nekem egy rendes blogmotort, mert ebbe egy kínszenvedés volt beleírni az előző forráskódos cuccost. Átlátható architektúrája legyen (pl. Spring, JPA) és lehet pehelysúllyú, azt könnyebb bütykölni.
Ja és egy ip-t is szeretnék, ahová 80-as portra rakhatom fel a glassfish-t, és nem kell közösködni minden mással httpd.apache-csal.
Mikrokernel és kampók
Az álmom továbbra is ugyanat. Egy j2ee-s (de legalább is web kontainerbe futó) mikrokerneles moduláris alkalmazást találni/írni. Néha, ha ez rámjön, akkor elkezdek guglizni, és olyanokról olvasok, mint a HiveMind, vagy az OSGi.
Az OSGi különösen szimpatikus, van benne dependency kezelés, modularitás, futás közben-i deploy. Az egyetlen, ami hiányzik ezekből a rendszerekből, az a hook rendszer, amire szintén ácsingózok.
Aztán belegondoltam és rájöttem, hogy ez teljesen érthető. Ha van lehetőség egy szolgáltatást (interface-t) publikálni, és azt más szolgáltatásokból meghívni, akkor a publish/subscribe minta szerint már vidáman lehet remek hook rendszereket képezni bármelyi felé.
Valahogy így képzelem:
1. van egy HookSystem.java, ahová regisztrálni lehet egy interface konkrét implementációit (akár többet is)
//publish service
public void create(Class interfacez);
//subscribe to service
public void register(Class interfacez,Object o);
//execute the hook
public Object getHook(Class interfacez);
Például:
HookSystem system = new HookSystem();
//publish
system.create(hookertest.Hook.class);
//suscribe
system.register(hookertest.Hook.class,new HookImpl1());
system.register(hookertest.Hook.class,new HookImpl2());
//get the executor
Hook hook = (Hook) system.getHook(hookertest.Hook.class);
hook.print("asdx");
Terménszetesen a két HookImpl* implementálja a Hook-ot.
2. és van egy parancs, ami meghívja az összes implementációt, aki regisztrálvan van. A vicc kedvéért ezt a HookSystem.getHook-on keresztül csinálnám, ami egy proxyt ad vissza a Hook interface-re, de bármit meghívva rajta az összes implementáló osztály végighívja a paraméterekkel (a visszatérési értékek kezelésén még gondolkozom, egyelőre legyen mindenki void, és a paraméterekbe irkálljon. Továbbá az is gyanús, hogy szép generic-kekkel még meg lehetne bolondítani az egészet.)
Hát így. Hook rendszerem van. Már csak valamelyik mikrokernel cuccost kéne átlátni.
Az OSGi különösen szimpatikus, van benne dependency kezelés, modularitás, futás közben-i deploy. Az egyetlen, ami hiányzik ezekből a rendszerekből, az a hook rendszer, amire szintén ácsingózok.
Aztán belegondoltam és rájöttem, hogy ez teljesen érthető. Ha van lehetőség egy szolgáltatást (interface-t) publikálni, és azt más szolgáltatásokból meghívni, akkor a publish/subscribe minta szerint már vidáman lehet remek hook rendszereket képezni bármelyi felé.
Valahogy így képzelem:
1. van egy HookSystem.java, ahová regisztrálni lehet egy interface konkrét implementációit (akár többet is)
//publish service
public void create(Class interfacez);
//subscribe to service
public void register(Class interfacez,Object o);
//execute the hook
public Object getHook(Class interfacez);
Például:
HookSystem system = new HookSystem();
//publish
system.create(hookertest.Hook.class);
//suscribe
system.register(hookertest.Hook.class,new HookImpl1());
system.register(hookertest.Hook.class,new HookImpl2());
//get the executor
Hook hook = (Hook) system.getHook(hookertest.Hook.class);
hook.print("asdx");
Terménszetesen a két HookImpl* implementálja a Hook-ot.
2. és van egy parancs, ami meghívja az összes implementációt, aki regisztrálvan van. A vicc kedvéért ezt a HookSystem.getHook-on keresztül csinálnám, ami egy proxyt ad vissza a Hook interface-re, de bármit meghívva rajta az összes implementáló osztály végighívja a paraméterekkel (a visszatérési értékek kezelésén még gondolkozom, egyelőre legyen mindenki void, és a paraméterekbe irkálljon. Továbbá az is gyanús, hogy szép generic-kekkel még meg lehetne bolondítani az egészet.)
Hát így. Hook rendszerem van. Már csak valamelyik mikrokernel cuccost kéne átlátni.
2006/11/26
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ó.)
2006/11/20
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á.
2006/11/13
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?
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?
2006/11/07
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.
(É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.
2006/11/03
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.
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.
Feliratkozás:
Bejegyzések (Atom)