Guice 2.0
Monday, May 25th, 2009 | Uncategorized | No Comments
Kijött a Guice 2.0. Sok egyébb mellett az én problémámra is megoldást nyújt. Azaz listener-ek segjtségével teljesen dinamikus bindingokat lehet létrehozni.
Eddig a @PersistenceContext injektálásokhoz előre meg kellett adni a a Module-ba a használni kívánt PU-kat. Most már lehet dinamikusan a classpathba keresni igény esetén, hogy létezik a megjelölt PU, és elég első injektáláskor betölteni. Tehát most már lehetne vele EJB konténert emulálni rendesen integrációs tesztkörnyezetben. (Kristóf ajánlotta wrap-persist mellett (emi elsősorban JPA barát) van egy GuiceFruit is, ami mintha részben tudná is ezt.(EJB barát is)).
Ez a Guice egyre jobban tetszik. Már több kissebb-nagyobb projektembe beszivárgott, és lassan kezdek függővé vállni.
ps: akinek volt commentje, ami moderácóra várt (ilyen eddig nem nagyon volt), az kérem írja újra, mert legalább 2000 spamet kaptam, és kénytelen voltam SQL-ből törölni.
OSGi névsorolvasás
Sunday, May 10th, 2009 | Uncategorized | 1 Comment
pax-runner: Az ops4j-sek azok, ahol nem csak a forráskód a szabad, hanem a fejlesztés is, tehát odamész, és ha akarsz, commitolsz. Az ő legnépszerűbb projekt csokruk a pax, amik mind OSGi-al foglalkoznak. A pax-runner pl. OSGi konténert indít el. Bármilyet, csak paraméterezni kell. Azt is megmondhatod, hogy milyen alap szolgáltatások legyenek benne. Ha nincs meg a konténer, amit szeretnél, akkor letölti. Nagyon jól lehet vele tesztelni bundle-t több konténerbe.
modulefusion: (K.-tól tanultam.) A recept egyszerű: végy egy csomó OSGi bundle-t (ha nincs elég jó, csinálj), és az egészet rakd össze valami alkalmazás szerver jellegű dolognak, és nevezd el. Ezt csinálja a Spring Source is, és ilyen a modulfusion is. Van benne wicket, guice, hibernate mindezt pax-runner indítja el, jól összerakott szakmunka. Példák is vannak, hogy hogy csináljunk JPA+Wicket+guice varázslatot OSGi konzolon.
equinox: az Eclipse OSGI konténere. Az izgalom az benne, hogy van hozzá egy server bridge. Ez egy war file, amit bedeployolsz bárhová, de közben OSGi konténer is. A servletre érkező kéréseket OSGi HttpService szolgáltatásként adja tovább. Valami ősöreg 3-as OSGi bundleok vannak benne.
Felix: Apache OSGi konténer. Kicsi, könnyű, beágyazható. Akik nem eclipse hívők (pl. Glassfish), azok általában ezt használják. Szerethető cucc, de nincs servlet bridge-hozzá. (még)
Http Service: OSGi kiegészítő specifikáció része. Kicsit buta, csak Servletet lehet regisztrálni. Azt is úgy, hogy lekéred a servicet, amin meg tudod hívni a regisztráló metódust. Mindenkinek szokott lenni implementációja, általában Jetty alapú.
Pax-web: egy másik pax. Olyan mint a Http Service (extend), csak van mellette még filter támogatás is, meg resource és jsp regisztráció, welcome file támogatás, stb. Servlet bridge nem tudja, mivel ez önmagában egy jettyre épülő bundle. Kicsit vendor lock-in, de szükség lehet rá (modulefusion a Wicketet servleten keresztül működteti, nem filteren, tehát megkerülhető).
Pax web extender, whiteboard: a http service-ek regisztrációját könyíti meg. Nem kell megkeresni a szolgáltatást, amin keresztül regisztrálni lehet a Servletet, hanem elég felírni a táblára, hogy én vagyok X Servlet az Y url-en, és már megy is. Meglepően okosan összerakott cucc: megy csak Http Service szolgáltatással, és pax-web-bel is. Megnézi milyen osztályok vannak, és azzal főz.
Felix File Install: egy okos bundle, ami sasol egy könyvtárat, és az ott feltünő bundle-okat hot deployolja.
modulefusion dir install: egy mégokosabb bundle, ami a modulfusion része, és nem csak a bundle-okat nyomja fel, de a config fájlokat is beolvassa.
Recept: fogom a Felix-et, berakom egy szervletbe, és onnan indítom, tehát elértem azt, amit az equinox servlet bridge is. Az OSGi compendium libraryt kicsit megpatkolva, pár class-t az OSGi class loadernek kiajánlva, és a HttpRequest wrappolása után, a pax web whiteboardon keresztül, a felix dir installt mellőzve, hanem az eredeti modulefusion-osat használva, a modulefusionos wicket-es guice-os OSGi-s csoda tökéletesen fut szervlet konténerbe. peace.
Most ez
Wednesday, April 29th, 2009 | Uncategorized | 1 Comment
Munka fronton éppen nagy kocka alakú dobozokban tárolt un. termékekkel kell megváltani a világot, ezen kívül csak lehulló morzsák, ezekről gyorsjelentés:
Guice: az egyik hobbi projektbe észrevétlen beszivárgott. Kb. azt adta amit vártam, meg vannak a korlátai, de azon belül okos kis kütyü. Egyelőre több könnyebbséget mint bosszúságot hozott, de ezzel az extension-nal még inkább csillogóbbá válhat a kép. Spring hívőknek nem való, de a hozzám hasonló egyszerű emberek ráérezhetnek a szépségére, hogy nem XML-eket kell túrni, hanem típusos Java kóddal kell definiálni a bindingokat (mégha cserépe tele szemeteljük a kódonkat annotációkkal).
Hg: egy két új projekt már ezen fut. Régebben nem tudtam elképzelni, hogy egy fejlesztő + egy központi szerver felállásban is lehet értelme, de most már abszolút úgy érzem, hogy igen. Egyre jobban kézreáll, csak az a baj, hogy egy LTS szerveren a pythonnal való összekalapáltság még eléggé durva (durván warningol de azért megy.) Meg a http feletti elérhetőséget se volt időm még előállítani.
Dbunit: eddig csak Unitils-el használtam, de Maven pluginjével DB környezetek közötti váltására is elég jó. Kárhogy sémát nem tárol. TODO: az inkrementális sémageneráló Maven plugint mégis csak be kéne fejezni.
Ezen kívül Wicket, Darkstar és mindenféle WS varázslat van most az erdőben, de ezekből még nem tudom mi lesz.
Google App Engine
Monday, April 13th, 2009 | Uncategorized | 2 Comments
Egyfelől egy elég jó hosting környezet, ugyan korlátozásokkal, de azokkal együtt lehet élni. Webes felület, áttekintés a használt erőforrásokról, verziózott deploy, nincs PermGen hiba, stb.
Másfelől habár elég sok mindent lehet futtatni rajta, korántsem problémamentes olyan alkalmazást fejleszteni, amit GAE-be is, és hagyományos webkonténerbe is ugyanúgy lehet futtatni.
Én rögtön a JPA kortlátozásaiba futottam bele. Egyrészt itt is örörm, hogy szép szabványos felületen adnak a BigTable fölé, még az se nagyon baj, hogy @ManyToMany-t nem használhatok, és hogy az entitás osztályaimat precompile-olni kell DataNucleus-szal.
De az már sokkal szűkebb keresztmetszet, hogy ha szülő-gyerek relációt szeretnék, akkor az elsődleges kulcsnak Stringnek, vagy Google specifikus Key osztálynak kell lennie. Egyiket se könnyű egy az egybe átültetni mondjuk Mysql + Hibernate JPA-ra. Persze tudom, itt nem az a cél, hogy a meglévő alkalmazások rögtön deployolhatók legyenek a GAE-be, hanem hogy az induló startup-omat kifejezetten Google-re fejlesztve skálázható teljesítményt kapjak, és azt is tudom, hogy a BigTable azért nem egy relációs adatbázis. És azt se mondhatom, hogy nem korrekt Java környezetet kapok hozzá. Csak valahogy jó lett volna, hogy ha kis ember Java hostingjának is jó lenne az egész. (Pl. ha az XWIKI-be fejlesztene valaki BigTable perzisztens layert…)
Maven vs. scripting
Saturday, March 14th, 2009 | Uncategorized | No Comments
Van egy régi félkész projekt, ami az előző munkánkból potyogott ki, mint újrahasznosítható alkatrész. A központi része egy absztrakt adatbázisséma reprezentáció Java osztályokból. Ezt az absztrakt fát fel lehet építeni többfajta forrásból (pl. Oracle DB connection alapján leképezi egy meglévő DB felépítését, vagy egy Jar-t megadva leképezi a Jpa entitások által meghatározott sémát az absztrakt adatbázis sémává). Természetesen az absztrakt DB sémát ki is lehet iratni (célszerűen mindenféle adatbázis specifikus SQLé). Illetve egy eszköz meg tudja mondani két sémadefiníció különbségét, és azt is le tudja képezni SQL parancsokká.
Mire jó? Mi két dologra használtuk. Egyrészt a JPA osztályokból előállítottuk azokat a fájlokat, amikben az SQL parancsok voltak, amivel a sémát fel tudtuk építeni. Ez már csak a Unitils-es teszt környezetünk miatt is kellett, ami, ha érezte, hogy az SQL-ek megváltoztak, a teszt adatbázist rögtön törölte, és felépített egy teljesen új adatbázist. Másrészt a fejlesztési adatbázist is tudta frissíteni, mert beolvasta a jelenlegi sémát (Oracle system táblákból), és az új sémát (JPA osztályokból), összehasonlította a kettőt, és a különbséget SQLben mondta el. Így a fejlesztési adatbázist (és akár az éleset is) tudtuk inkrementálisan frissíteni, úgy hogy a meglévő tartalom ne vesszen el.
Most jön a lényeg. A projektet kicsit kipofoztam múltkoriban, és már ott tartok, hogy csináljak hozzá ANT taskot és Maven plugint. Azon gondolkoztam, hogy hogyan tudnám a konfigurálhatóságot úgy megragadni, hogy az egyes elemeket bármilyen párosításban lehessen használni. Bárhonnan tudjak sémát beolvasni (létező Oracle vagy Mysql séma, JPA osztályok), és bármit meg tudjak velük csinálni (Mysql vagy Oracle specifikus kiiratás, összehasonlítás különbség számítás).
Arra gondoltam, hogy a legrugalmasabb az lenne, ha nem az XMLen kéne erőszakot tenni, hanem mondjuk valami scrip nyelvel lehetne megfogalmazi, hogy mit akarok, és milyen összetételben.Az első tesztek szerint a JSR-223 teljesen jó megoldást adna, mindenki abban írhatná meg a logikát, amiben akarná, akinek meg mindegy, annak ott az alapértelmezésben is elérhető JavaScript motor a Rhino. Ez utóbbival (a még teljesen átgondolatlan API) valahogy így föst:
new DDLWriter();.generateDDL(new JPAReader(”target/test-classes”).readDefinition()).printAll();
Az elképzelés az, hogy csinálok egy Maven plugint, amibe ezt bele lehet írni konfigurációként. Persze ez rögtön általános Maven plugin lenne, amibe bármit lehetne írni bármilyen JSR-233az script nyelv segítsévégel. Akár már létezhetne is ilyen plugin (rákerestem, nem találtam), amivel ha mást nem a Maven kicsit merev logikáján és deklaratív eszméjén sikerülne rést ütni. Valahogy úgy mint az antrun plugin, csak itt ráadásul scripteket lehetne írni ANT XML részletek helyett.
És itt, hogy ne nyúljak túl hosszúra, inkább Szczepan Faber-t a Mockito szerzőjét idéznem:
“After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature.”
JMeter
Sunday, March 8th, 2009 | Uncategorized | No Comments
Bár amikor terheléses teszt kell, mindenhol fel szokott az Apache Jmeter neve is merülni, huzamosabban most használtam előszőr.
Ami tetszett:
Felépítés: Tetszett, ahogy ki vannak találva az egyes építőkockkák, amikből tesztet lehet csinálni. Külön van protokoll függő meghajtó, külön vannak logikai elemek, külön mindenféle eredményt analizáló elem. A GUI-n ezekből az elemekből lehet viszonylag könnyen terheléses tesztet összerakni. Mégha nem akartam volna a meglévő komponenseit használni, mint keretrendszer, az interface-eket akkor is valószínű használtam volna.
Dokumentáció: a honlapon elég tisztességesen le van írva minden a használatról, és a használható elemekről.
Szállított elemek: okos ötletek vannak az alapból szállítótt teszt elemekben: pl. tud olyat, hogy egy webszerver logja alapján ismétli meg a hívásokat a szererre, és így valós felhasználói viselkedést lehet szimulálni vele. Van olyan elem is, amivel hagyományos Java kódot tud meghajtani, amibe már azt írunk, amit csak szeretnénk.
Könnyen kiterjeszthető: Egyszerű interfacek, használható absztrakt osztályok. Csak leszármaztatunk egy osztályt, bedobjuk a lib/ext könyvtárba, és már is megjelenik a mi építőkockánk is. (Durván végig scanneli a classpathnak ezt a részét osztályról osztályra, ezért a saját komponensünk függőségeit érdemes a sima lib könyvtárba tenni, mivel abban nem kell keresni a leszármaztatott JMeteres osztályokat, és túl nagy osztályok az indítást nagyon vissza tudják fogni.)
Ami nem tetszett:
Szállított elemek: A szállított elemek sokszor elég szegényesek. Főleg a grafikonokat megjelenítő elemek elég fapadosak (a managerednek nem lesz elég szép), de pl. a JMS Sampler-ben is voltak gondjaink a Correlation ID beállítása körül, illetve a külső paraméterek kezelése is kissé fapados.
Paraméterek átadása: paraméterezett teszteket csinálni két féle képpen lehet: User Definied Variableket használva, és System propertyket. Az előbbik vannak kényelmesebben integrálva a rendszerben, az utóbbiakkal lehet rendesen paraméterezni command line-ból indítot teszteket. A kettő között van átjárás, de nem túl kezes.
Gyanús hibák: Nem volt idő végigdebuggolni, de volt egy olyan jelenség, hogy sok-sok szálon nyomtam épp egy web service-t, valószínű hibás paraméterekkel. Feltehetően loggolni akarta a hibákat, én csak azt láttam, hogy teljesen megállt minden. jconsole azt mondta, hogy a sok szál általában vár egy lock-ra, ami valami apache logos osztályban keletkezett (Illetve iszonyú lassan mindig eg yszál loggolt, amíg a többi várt a szemaforra)). Magyarul a logolás szinkronizációja miatt kicsit megroppant az egész teszt.
Összességében nem rossz, a használatáról az egyik koléga mesélte még rémtörténetet: ha jól emlékszem egy IIOP-s vastag klienset sikerült velük meghajtani, úgy, hogy előtte AOP-vel le loggolták a kéréseket a kliensben, és utána ezeket az adatokat táplálták be a JMeterbe, ami megterhelte a rendszert velük. Szép dolgokat építeni belőle.
Munkák és napok
Wednesday, January 14th, 2009 | Uncategorized | No Comments
Az úgy van, hogy én igyekszem mindig pozitívan hozzáálni a világhoz, csak sajnos mikor konkrétan használni akarom a dolgokat valahogy mindig kiderül, hogy nem úgy hajlik, ahogy én szeretném. Ma bent ismét előjött, hogy egy kritikai attitűdű Java-s blogot kéne írni, ami nem kertel, hanem kitér a termékek és szoftverek minden problémájára: valós képet fest a világról. Kedves blog lenne, olyan igazán megkeseredett hangvételle, és kerülné még a látszatát is, hogy valamit pozitívan méltasson.
Csak hogy kicst érzékeltessem a dolgot szeretnék két momentumot leírni a napomból:
Délelőtt felmerült egy kérdés a Glassfish loadbalancing tulajdonságát illetően, aminek jó lett volna utána nézni. Egyikünk a nyílt forrást, a másikunk a decompileolt változatot nézte, kinek mi akad hamarabb a kezeügyébe, míg meglett a válasz. De ezen folyamat alatt kiderült, hogy Build instructions tényleg nem viccel, a Glassfish 2 tényleg csak Maven 1.0.2-vel forgatható. Nem elég hogy Maven 1, de abból is az a változat, amit már le se lehet tölteni az Maven oldalról (az aktuális az 1.1-es), hanem az archive.apache.org-kell kibányászni, hogy menjen.
A délután nevezetes eseménye meg az volt, hogy Oracle SOA Suite-et telepítettem (próbáltam), hogy kicsit kipróbáljam, és rajta keresztül még inkább átérezzem az élet nagyszerűségét. Le is töltöttem a röpke 700 megás telepítőt (az Oracle telepítők mindig 700 megásak, bármit is akarsz letölteni, ha nincs akkora a szoftver, akkor melléraknak nullákat meg egyeket, hogy kijöjjön a CD). A telpítőt a nagyszerű cpio-val csomagolták be, hogy még azt is meg kelljen keresni, hogy milyen kapcsoló kell ahoz, hogy rendesen kicsomagolódjon, mert a cpio alapból könyvtárakat nem tömörít ki, csak fájlokat, de azt meg csak akkor, ha megvan a könyvtár, amibe a fájlnak kerülnie kell. Szóval elindítom a telepítőt, ami némi kattogás után közli, hogy ez a linux (Ubuntu) nem a Linux, mert ő csak Red Hat Enterprise izén hajlandó futni és esetleg Susén, de abból 9esen (a világ OpenSUSE 11.1-nél tart.) és különben meg szevasz.
Mit mondhatnék, alja egy világban élünk. Tényleg kéne az a blog.
(Ha lesz időm holnap már tényleg leírom a Gradle-s tapasztalataimat a múlt hétről, és lesz benne (valamennyi) pozitív (is). Köszönöm, hogy meghallgattak.)
JMX és JBI
Sunday, January 4th, 2009 | Uncategorized | No Comments
Ott hagytam abba múltkor, hogy milyen jó, hogy a JBI specifikáció beszél a deployolás és menedzsment témaköréről is, és ANT taskokat valamint JMX bean-eket definiál. (Vesd össze EJB specifikációt, ahol minden menedzsment funkció gyártófüggő).
Nagy örömömben akartam is írni egy egyszerű eszközt, ami alapműveleteket tud elvégezni bármilyen JBI konténeren. Beleástam magam a JBI és a JMX bugyraiba, és rögtön jöttek is a gondolok:
A JBI specifikáció definiálja az MBean interface-eket, amiket implementálni kell, de azt nem, hogy az MBean-eket milyen domain alá kell regisztrálni, így mindenki a saját domain alá regisztrálja a JMX fában a szabvány szerint implementált MBean-jeit. Az lenne a jó, ha lenne egy olyan JMX metódus, amivel egy adott interface-t megvalósító MBean-eket kérem le, de ezt a funkciót sehogyan sem sikerült életre keltenem.
Elvileg van egy isInstanceOf metódus az MBeanServerConnection osztályon (amit a Query API is használ), de ennek a dokumentációja elég körmönfont:
Returns true if the MBean specified is an instance of the specified class, false otherwise.
If
namedoes not name an MBean, this method throwsInstanceNotFoundException.Otherwise, let
X be the MBean named byname,
L be the ClassLoader of X,
N be the class name in X’sMBeanInfo.If N equals
className, the result is true.Otherwise, if L successfully loads both N and
className, and the second class is assignable from the first, the result is true.Otherwise, the result is false.
Azaz ClassLoader-től függ, hogy mit ad vissza. OpenESB-nél úgy néz ki, hogy a szabványos MBean interface-t leszármaztatja egy com.sun-s interface és annak van implementációja. A com.sun-os interfacre működik az isInstanceOf alapú keresés de ami lényeg lenne a javax.jbi.management-re nem lehet, úgy tűnik azért mert különböző ClassLoader-ek töltik be a com.sun és a javax.jbi osztályokat.
Elvileg találtam utalásokat, hogy a Java 7-ben ez meg lesz jobban oldva (heló 2010). Láttam nyomait továbbá egy valaha létezett JBI Maven pluginnek (forrását nem sikerült elérni), ami deployolni is tudott. Nagyon érdekelne, hogy ott hogy sikerült megoldani a problémát. A ServiceMix-hez szállított ANT taskok forrását megnéztem, ott hardcode-olva vannak a ServiceMix-es MBean-ek címei.
JBI 1.0
Thursday, January 1st, 2009 | Uncategorized | No Comments
Olvasgatom a Java Business Integration specifikációt, nem egy könnyű olvasmány: pl. az EJB specifikáció véleményem szerint sokkal olvasmányosabb (annak ellenére könnyebb átlátni, hogy háromszor annyi oldal).
Akik nem ismernék, annak tájolásképpen: egy SOA-s szabványról van szó, ami az Enterprise Service Bus (ESB) mintát valósítja meg. Lényegileg egy közös üzenetet közvetítő busz köré lehet komponenseket telepíteni. Ebből logikailag két fajta van: Binding Component (BC) és Service Component (SC). A BC-k tipikusan a külvilágból jövő kéréseket konvertálják belső XML-es üzenetekké (tipikus BC-k: SOAP, REST, Email, FTP, XMPP,…), az SC-k pedig általában e buszon szaladgáló üzeneteket alakítgatják vagy a business processt irányítják (tipikus SC-k: XSLT, BPEL, EJB, Scripting). Ezeket lehet össze drótozni a busz mentén, sőt a komponensekbe még lehet deployolni további adatokat (pl. XSLT processorba XSLT-t, BPEL motorba BPEL fájlt, stb).
Számomra a jelenleg problémás részek (én ezeket olvastam ki, de javítsatok ki, ha nincs izagazam).
1. Ha jól értem, akkor a komponensek routolása egyáltalán nem található ki sehonnan. Bár lehet a jbi.xml-ekben routing adatokat megadni, ez egyáltalán nem kötelező. Sok helyen láttam, hogy a a BC-kbe és SC-kbe amikor beledeployolunk akkor egy WSDL-t is deployolunk (A fent elmlített XSLT, BPEL, stb.-k mellett), és ebben a WSDL-ben definiáljuk, hogy milyen endpointot hív meg a komponenes / milyen címen hívható meg. Ez a deployolás azonban teljesen komponenes függő, semmilyen API nincs, amiből utaná kideríthető lenne a routolás.
2. ESB-ről van szó, tehát egy közös buszon közlekednek az üzenetek. Az üzenetet fel lehet küldeni a buszra, valamit ki lehet róla olvasni az üzenetet, de a kiolvasás nem valami listener jellegű interface-en keresztül megy, hanem pollozással. Emiatt ha több szálon szeretnénk feldolgozni az üzeneteket jó eséllyes valami saját thread pooling megoldást kell implementálnunk.
Message reception always follows the “pull” model: the JBI component MUST pull the message exchange instance from the DeliveryChannel, using its own thread of execution. Components MAY use more than one such thread, allowing concurrent message reception by the component. The JBI implementation MAY satisfy multiple accept() requests from a single component in arbitrary order.
(JBI 1.0 spec, 44. oldal)
Továbbá a Future Directions fejezetből (205. o.):
Adoption of a work manager (from another JSR) to allow components to not have to manage their own threads.
Erre persze az a megoldás, hogy minden JBI gyártó csinál saját könyvtárat, ami a JBI nagyon alacsony szintje fölött még egy kényelmesebb absztrakciós szintet ad. (Pl. az OpenESB-nél ezt nevezik Component Toolkit-nek).
Mindent összevetve a JBI mint specifikáció még nem győzött meg. Ha nem lenne adottság lehet, hogy alaposabban megismerkednék az előző bejegyzésekben ajánlott Mule-val, ami szabványt nem implementál, de cserébe okos és egyszerű eszköznek tűnik.
Bár az is lehet, hogy ha tovább elmélyedek a JBI-ben nég változik a véleményem. Az például nagyon jó benne, hogy JMX alapú management API-t ad komponenesek telepítéséhez, deployolásához, stb.
JBI próbákozások
Saturday, December 27th, 2008 | Uncategorized | 3 Comments
Régebben egyszer már volt egy ESB-s/JBI-s korszakom, de most úgy tűnik, hogy a munkám is erre fog kanyarodni a jövőben. Elkezdtem hát nézegetni újra az OpenESB-t és más alternatív JBI implementációkat.
(Figyelmeztetés: a következő megjegyzések nem tükrözik az egyes szoftverek minőségét, csupán olvasónapló szerű megjegyzések találkozásokról.)
OpenESB: előszőr evvel próbáltam gyorsan képbe kerülni. Ha jól értem GlassfishESB-néven fut kitüntetett és terjesztett változat, és most van belőle RC. Régen volt egy olyan vonulat, hogy command line-ból is futtatható legyen, ennek aktuális változatát nem találtam. Gondolom a következő generációs OSGIre épülő változat, majd tudni fogja, és addig már nem nagyon. A Fuji viszont ha jól értem a 2009-es J1-re lesz csak Technology Preview, tehát nem lesz aktuális a kövekező időszakokban.
Nemrég tanuja voltam, ahogy valaki próbál konzolból forgatni egy OpenESB-s alkalmazást (alapból ezt a hozzá kapott NetBeans-szel lehet). Hát a szokásos ANT-os library varázslatok kellettek hozzá, csak a Jar filok egy része ráadásul a NetBeans része volt, és onnan kellett volna előbányászni. A mai világban, amikor a CI már elég alap dolognak számít, azért elvárnám, hogy ne kelljen vért pisálni a konzolos fordításhoz.
Még -1: NetBeans 6.1-et adnak alapból az ESB-hez, mert ahhoz vannak jól meg a pluginek (nem NB hívőknek: 6.5 az aktuális verzió)
ServiceMix: Apache projekt. Ehhez már nem kell alkalmazás szerver, futtatható konzolból is. A 3-as verziójú család támogatja a JBI szabványt, a 4-es az OSGi-t. A 4.1-es fogja mindkettőt. Tehát egyelőre a 3-asnál maradok.
Elfog a kisördög, és megpróbálom tesztelni a JBI kompatibilitását úgy, hogy az OpenESB-be deployolom a részeit. Sajnos a shared library komponens nem tartalmaz mindent (a ServiceMix classpath-ában benne van a commons-logging, de ez nem várható el minden JBI konténertől), ezért nem futnak a BC-k OpenESB-n. Egy minusz pont. A legegyszerűbb példa alkalmazás szintén nem JBI kompatibilis, mert a jbi.xml leíró nincs rendesen legenerálva: -2.
Ezekel a kellemetlen dolgokat leszámítva nem néz ki rosszul a dolog, van hozzá pl. sok barátságos Maven plugin, és elég részletes dokumentáció.
PEtALS, ez meg OW2 projekt. Erre jutott még a legkevesebb idő, (=ezzel foglalkozom éppen most) de ez is kedves kis cuccnak tűnik. A komponenesek általában tartalmazzás az összes függőségüket is, simán sikerült depoyolnom az OpenESB-be egyet. Van hozzá webes konzol és onnan is lehet deployolni.
Következő feladat: újra átfutni a JBI speckót. (Illetve utánanézni, hogy mikor lesz már JBI 2.0).
Recent Comments
- Zs on Google App Engine
- Zs on Most ez
- Kristof on OSGi névsorolvasás
- pcjuzer on Google App Engine
- Jozsa Kristof on JBI próbákozások