A JCR egyik hibájának szokták felróni, hogy nincs hozzá jó admin eszköz (~pgAdmin, Toad). Kezdemények azért szerencsére már vannak. Ma kettő került az utamba: A JCR Controller és a JCR Browser.
Minkettő elég jó funkcionalitást biztosít, írni olvasni, exportálni importálni lehet mindent. A JCR Controller webstartról indítható standalone program (screenshot), de sajnos 1280x87.. ra optimalizálták. Ezt azt jelenti, hogy 1024x768-as felbontásban egyes mezők nem is láthatóak, nem érthetőek el. Ez azért eléggé lecsökkenti a használhatóságot. (Már aki szintén sajnálta a pénzt, monitorra).
A JCR Controller, szintén friss fejlesztés, egy war file-t kell deployolni, tehát webes, és belépéshez a repository JNDI címe és egy login név kell. A kedves dolog az benne, hogy mivel tudja ugyanazt a repositoryt használni, amit a webalkalmazásom, ezért nem kell JCR-RMI-t feltelepítenem, hogy megnézzem mi van épp a repositoryban. Még elég nyers (pl. idiot-sicher validálások sokszor hiányoznak), de működő és használható. Egyelőre ez marad.
BTW, kijött a JCR 2.0-ből a Public Review.
2007/07/16
Széljegyzetek process killezéshez
Még a múlt hétvégéről maradt itt egy cetli, amin két dolog áll:
Egyrészt a Runtime.getInstance().addShutdownHook() Ami egy elindítatlan szállat ad a JVM-nek, hogy amikor meggyilkolja valaki a programunkat, a JVM becsukása előtt még lefutassa a szálunkat. (ctrl+c vagy kill esetén még lefut, de kill -9 esetén persze nem). Nagyon szép lehetőség fusizásra, és nyilván szép megoldásokra is.
A másik, hogy kill -3 parancsra a Sun (gyanítom, ez nincs specifikálva általánosan) JVM kiadja a futó java thread-ek stack trace-ét. Szegény ember JConsol-ja. Valamikor még hasznos lehet.
Egyrészt a Runtime.getInstance().addShutdownHook() Ami egy elindítatlan szállat ad a JVM-nek, hogy amikor meggyilkolja valaki a programunkat, a JVM becsukása előtt még lefutassa a szálunkat. (ctrl+c vagy kill esetén még lefut, de kill -9 esetén persze nem). Nagyon szép lehetőség fusizásra, és nyilván szép megoldásokra is.
A másik, hogy kill -3
2007/07/13
Java User Meetings II.
Ezzel a beszámolóval még adós vagyok:
Az első előadás az enyém volt, JBI-ról szólt. Egy kicsit lelkiismeret furdálásom volt utána. Miután végig fikáztam a TSSJS EU előadásait, aztán pedig észrevettem, hogy én is ugyanazt csinálom, ami máshol nem tetszett (pl. elcsúszok az idővel). Mindegy, azért remélem legalább néhány embernek hasznos volt.
A Dojo és Wicket előadásokról együtt: nekem mindkettő nagyon bejött. Jó fáradt voltam, de ébren tartottAK, mindkettő sok kódot mutatott, de nem tévedtünk el benne, de kaptam valami érzést, hogy milyen is belül kb. a felépítése a két dolognak. És átjött pl. hogy a javascriptnek igen is lehet szépsége az, amikor aspektus orientált dolgokat csinálunk kihasználva a kevsébé típusosságát, vagy hogy egy keretrendszer, ami nem akarja megváltani a világot, csak egyszerű és jól használható akar lenni, szépen megírva, az igen is perspektíva. (Tegnap este le is ültem Wicket-ezni, hogy kipróbáljam).
Szóval, ha voltak még az első alkalom után kétségeim, akkor most teljesen elszálltak. Jó arcok voltak, és jó értő kérdések. Számomra a megszerzett tapasztalat verte a sokszor szokásos marketinges-evangelizációs előadások információs tartalmát.
Az első előadás az enyém volt, JBI-ról szólt. Egy kicsit lelkiismeret furdálásom volt utána. Miután végig fikáztam a TSSJS EU előadásait, aztán pedig észrevettem, hogy én is ugyanazt csinálom, ami máshol nem tetszett (pl. elcsúszok az idővel). Mindegy, azért remélem legalább néhány embernek hasznos volt.
A Dojo és Wicket előadásokról együtt: nekem mindkettő nagyon bejött. Jó fáradt voltam, de ébren tartottAK, mindkettő sok kódot mutatott, de nem tévedtünk el benne, de kaptam valami érzést, hogy milyen is belül kb. a felépítése a két dolognak. És átjött pl. hogy a javascriptnek igen is lehet szépsége az, amikor aspektus orientált dolgokat csinálunk kihasználva a kevsébé típusosságát, vagy hogy egy keretrendszer, ami nem akarja megváltani a világot, csak egyszerű és jól használható akar lenni, szépen megírva, az igen is perspektíva. (Tegnap este le is ültem Wicket-ezni, hogy kipróbáljam).
Szóval, ha voltak még az első alkalom után kétségeim, akkor most teljesen elszálltak. Jó arcok voltak, és jó értő kérdések. Számomra a megszerzett tapasztalat verte a sokszor szokásos marketinges-evangelizációs előadások információs tartalmát.
2007/07/11
Száz
Kicsit több mint egy éve kezdtem el ezt a blogot írni, és most elértem a századik bejegyzést. Szeretnék most valami nagy és ünnepélyes dologt írni, de nem tudok igazán mit. Hétköznap van, egész éjjel hegesztettem az előadásomat, a meló meg megy tovább. Mindenesetre köszönök minden visszajelzést/látogatást/olvasást.
Vannak terveim a jövőre is, ennek az első jele, hogy a domain megváltozott (jtechnics.anzix.net alatt érhető el mostantól az oldal, meg persze a régi URL is működik). Ez (amellett hogy a mivel a problem szó kikerült a címből, a problémamentesség illúzóját adja nekem), egy régi terv első lépése, amikor is előbb utóbb át fogok állni egy saját JCR alapú blog motorra. (Tudom sok ingyenes is van, de én szeretnék JCR-es oldalt írni). Meg talán más dolgok is lesznek, de ezeket majd szeptemberben, ha visszajövök a szabadsáról.
Stay tunned, és köszönök mindent.
ui: Nem szeretem a bejegyzéseket, ahol nincs szó Javaról, úgy hogy itt egy link OSGi+Guice összeházasításáról. Bár ahogy én tudom service registry jelegű dolog az OSGi van, de talán nem elég injektálós. Nem tudom, de egyszer még utána kéne nézni, most nincs időm véigi bogarászni.
Vannak terveim a jövőre is, ennek az első jele, hogy a domain megváltozott (jtechnics.anzix.net alatt érhető el mostantól az oldal, meg persze a régi URL is működik). Ez (amellett hogy a mivel a problem szó kikerült a címből, a problémamentesség illúzóját adja nekem), egy régi terv első lépése, amikor is előbb utóbb át fogok állni egy saját JCR alapú blog motorra. (Tudom sok ingyenes is van, de én szeretnék JCR-es oldalt írni). Meg talán más dolgok is lesznek, de ezeket majd szeptemberben, ha visszajövök a szabadsáról.
Stay tunned, és köszönök mindent.
ui: Nem szeretem a bejegyzéseket, ahol nincs szó Javaról, úgy hogy itt egy link OSGi+Guice összeházasításáról. Bár ahogy én tudom service registry jelegű dolog az OSGi van, de talán nem elég injektálós. Nem tudom, de egyszer még utána kéne nézni, most nincs időm véigi bogarászni.
2007/07/09
AntUnit
Az AntUnit egy viszonylag friss projekt (pl. nekem csak 1.7-es ANT-tal ment rendesen). Célja, hogy ha ant taskokat csinálunk, (vagy mindenféle antot kiterjesztő varázslatot) egyszerű legyen tesztelni. A dolog nagyon egyszerű:
Ha a fájlt egy egy másik ant xml fájlból au:antunit taskkal hívjuk meg, akkor a test kezdetű targatek fognak lefutni. (meg persze a setUp, tearDown), és az assertek nek igaznak kell lenniük. Ami miatt viszont nagyon jó a dolog, az az ért van, mert ha csak úgy minden flikkflakk nélkül lefuttatjuk az xml-t, akkor lefut hagyományos módon. Pont mint a javaban a (sose használt) assertionok: ha bekapcsolom beszól, ha nem nem.
Annál mindenesetre szebb, mint amilyen Junit-os hackeket csináltam eddig.
<project xmlns:au="antlib:org.apache.ant.antunit">
<!-- is called prior to the test -->
<target name="setUp">
<property name="foo" value="foo"/>
</target>
<!-- is called after the test, even if that caused an error -->
<target name="tearDown">
<delete file="${foo}" quiet="true"/>
</target>
<!-- the actual test case -->
<target name="testTouchCreatesFile">
<au:assertFileDoesntExist file="${foo}"/>
<touch file="${foo}"/>
<au:assertFileExists file="${foo}"/>
</target>
</project>
Ha a fájlt egy egy másik ant xml fájlból au:antunit taskkal hívjuk meg, akkor a test kezdetű targatek fognak lefutni. (meg persze a setUp, tearDown), és az assertek nek igaznak kell lenniük. Ami miatt viszont nagyon jó a dolog, az az ért van, mert ha csak úgy minden flikkflakk nélkül lefuttatjuk az xml-t, akkor lefut hagyományos módon. Pont mint a javaban a (sose használt) assertionok: ha bekapcsolom beszól, ha nem nem.
Annál mindenesetre szebb, mint amilyen Junit-os hackeket csináltam eddig.
2007/07/05
OSGi server-side
Még rég volt utoljára, amikor az OSGi-vel foglalkoztam, akkor még amikor a Server-side OSGi szóba került, a FAQ-k általában azt mondták, hogy ne kelljen nekem olyan, mert úgy is van OSGi webserver bundle, és na akarjam meglévő appszerveremet használni. Ami azért nem annyira szimpatikus hozzáálás.
Most a TSSJS EU-n láttam egy bemutatót, hogy az Equinoxra (az Eclipse alatt lévő OSGi implementációra) elkészült egy servletes bridge is.
A dolog nagyon egyszerű:
Ha deployolni akarsz bele OSGi dolgokat, arra is ott van a példa. Persze csak Eclipse-el fordítható (Ant?, Maven?), de utána a kapott jar-t már deployolhatjuk az OSGi konténerbe:
install file:///home/user/samplehttp.jar
Utána ss paranccsal látjuk, hogy megette-e, és start number paranccsal indíthatjuk is (a number az ss-sel kiírt sorszámot jelenti.) Még egy ss és látjuk, hogy a sample.http_1.0.0 Active. Nézzük is meg a http://localhost:8080/bridge/helloworld címet, és működnie kell a szervernek.
Ezek után, ha a JAR-t újra fordítjuk a konzolból újra tölthetjük anélkül, hogy a servletünk leállna, ami teljesen rendben van.
Belenézve a samplehttp forrásába két érdekes dolgot látunk. Egyrészt az Activator (ami betöltéskor hívódik meg) regsiztrálja a servletünket a context alá:
httpService.registerServlet("/helloworld", new HelloWorldServlet(), null, null);
Logikusnak hangzik, mivel innentől egy szerverünk van, ami alatt komponensek és a fő szervletnek a web.xml-éhez már nem nyúlhatunk, hogy a servlet mappinget piszkáljuk.
A másik, hogy az egész kódban sehol se hivatkoznak eclipse.org osztályra. Azaz az egész servletes regisztrálós dolog az OSGi szabvány része, valamint valószínű a szabvány további szolgáltatásai is (pl. Logging services) konkrét interfacek megadását is jelentik. (Ez még ellenőrizendő).
Mindenesetre pazar cucc az egész moduláris web alkalmazások írására, mivel a class loader nyűgöket rendesen kezeli az OSGi, és alapból neked csak annyit kel csinálni, hogy ésszerűen modulokba rendezn a kódot és szétcsapni részekre. És akkor persze majd lehet csinálni az extension pontokat, (erre is van benne támogatás, csak még nem láttam).
(BTW megalakult a JSR-316 néven a JAVAEE 6, ami újra felkavarta a JSR-277 vs. OSGi vitát, mivel egyértelműen leszögezte, hogy mivel a JAVAEE 7 JSR-277-re fog épülni, ezért szó sem lehet OSGi-ról. )
Most a TSSJS EU-n láttam egy bemutatót, hogy az Equinoxra (az Eclipse alatt lévő OSGi implementációra) elkészült egy servletes bridge is.
A dolog nagyon egyszerű:
- Töltsd le innen a bridge.war-t.
- Deployold egy web containerbe.
- Indítsd el a webcontainer-t úgy, hogy a standard input megmaradjon (defaultból da kapod az OSGi konzolt). Tomcat-ben pl. a ./catalina.sh run a nyerő megoldás.
Ha deployolni akarsz bele OSGi dolgokat, arra is ott van a példa. Persze csak Eclipse-el fordítható (Ant?, Maven?), de utána a kapott jar-t már deployolhatjuk az OSGi konténerbe:
install file:///home/user/samplehttp.jar
Utána ss paranccsal látjuk, hogy megette-e, és start number paranccsal indíthatjuk is (a number az ss-sel kiírt sorszámot jelenti.) Még egy ss és látjuk, hogy a sample.http_1.0.0 Active. Nézzük is meg a http://localhost:8080/bridge/helloworld címet, és működnie kell a szervernek.
Ezek után, ha a JAR-t újra fordítjuk a konzolból újra tölthetjük anélkül, hogy a servletünk leállna, ami teljesen rendben van.
Belenézve a samplehttp forrásába két érdekes dolgot látunk. Egyrészt az Activator (ami betöltéskor hívódik meg) regsiztrálja a servletünket a context alá:
httpService.registerServlet("/helloworld", new HelloWorldServlet(), null, null);
Logikusnak hangzik, mivel innentől egy szerverünk van, ami alatt komponensek és a fő szervletnek a web.xml-éhez már nem nyúlhatunk, hogy a servlet mappinget piszkáljuk.
A másik, hogy az egész kódban sehol se hivatkoznak eclipse.org osztályra. Azaz az egész servletes regisztrálós dolog az OSGi szabvány része, valamint valószínű a szabvány további szolgáltatásai is (pl. Logging services) konkrét interfacek megadását is jelentik. (Ez még ellenőrizendő).
Mindenesetre pazar cucc az egész moduláris web alkalmazások írására, mivel a class loader nyűgöket rendesen kezeli az OSGi, és alapból neked csak annyit kel csinálni, hogy ésszerűen modulokba rendezn a kódot és szétcsapni részekre. És akkor persze majd lehet csinálni az extension pontokat, (erre is van benne támogatás, csak még nem láttam).
(BTW megalakult a JSR-316 néven a JAVAEE 6, ami újra felkavarta a JSR-277 vs. OSGi vitát, mivel egyértelműen leszögezte, hogy mivel a JAVAEE 7 JSR-277-re fog épülni, ezért szó sem lehet OSGi-ról. )
Feliratkozás:
Bejegyzések (Atom)