Java osztályok tárolása MySQL adatbázisban

A cím talán megtévesztő lehet, most nem arról van szó, hogy hogyan lehet szérializált osztálypéldányokat tárolni adatbázisban. Ehelyett magukat a Java osztályokat (típusokat) tárolom ilyen módon. Ez megtehető, hiszen a Java futásidőben tölti be az osztályokat, egészen pontosan az osztály első aktív használata elött. A továbbiakban a cikk feltételezi a Java és a MySQL alapszintű ismeretét, és a [[http://java.sun.com/javase/technologies/database/|JDBC]] használatát se fogom részletezni. Kezdetnek essen pár szó a Java osztálybetöltő mechanizmusáról.

A Java ClassLoader osztály használható arra, hogy egy keresett osztályt betöltsön a memóriába. Minden JVM indulásakor létrejön egy alapértelmezett rendszer ClassLoader, és ha nem teszünk semmit ez marad végig az egyetlen ilyen jellegű objektum a JVM-ben. A ClassLoader-ek működésének megértéséhez meg kell ismernünk néhány metódusát:

  • A konstruktor: ClassLoader(ClassLoader parent) : Minden ClassLoader-nek létezik pontosan egy szűlője (kivéve az alapértelmezett ClassLoader-t), ugyanis mielött az adott ClassLoader megpróbálná betölteni a keresett osztályt, megkérdezi a szülőt, hogy ő be tudja-e tölteni, és csak akkor próbálkozik meg, ha a még nincs betöltve, és a szülő sem tudja betölteni.
  • Class loadClass(String name) :ez hívódik meg, amikor felmerül az igény egy osztály betöltésére. Ez a metódus elöször meghívja a szülő ClassLoader hasonló metódusát, és ha az ClassNotFoundException-t dob, akkor meghívja ezen osztály findClass metódusát.
  • Class findClass(String name) :a fentiekből látszik, hogy ez a metódus hívódik meg akkor, ha már ránk hárult az osztály betöltésének a feladata. Ha új ClassLoader-t írunk, rendszerint ezt a függvényt akarjuk felülírni.
  • Class defineClass(String name, byte[] b, int off, int len) :ez a lényeg. Ez a függvény hozza létre az osztályt a memóriában a beolvasott bytecode-ból, aminek meg kell egyeznie egy “.class” fájl tartalmával.

Már látszik a turpisság: a fentiek alapján lehet írni egy ClassLoader-t, ami nem fájlból, hanem adatbázisból olvassa be a megfelelő bytesorozatot. Első lépésként írjuk meg az adatbázis réteget, ami a kérdéses bytecode-ot tudja menteni/kiolvasni az adatbázisból (az adatbázisba a bytecode-ot Base64 kódolásban mentem, amit egy segédosztály végez. Lásd: lent. Ugyanúgy nem térek ki a File beolvasására, annak a megoldásában is a Google segített):


package mysqlclasses;

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;

public class ClassSaver {

public static byte[] getBytesFromFile(File file) throws IOException {
.....
}

public static void saveToDB(Connection con, String name, byte[] data){
try{
Statement s = con.createStatement();
s.execute("CREATE TABLE IF NOT EXISTS classes (name VARCHAR(120) NOT NULL,bytecode TEXT)");

String bytecode = new String(Base64Coder.encode(data));

ResultSet rs = s.executeQuery("SELECT * FROM classes WHERE name = '"+name+"'");
if (rs.next()){
//update
s.execute("UPDATE classes SET bytecode = '"+bytecode+"' WHERE name = '"+name+"'");
}else{
//insert
s.execute("INSERT INTO classes SET name = '"+name+"', bytecode = '"+bytecode+"'");
}
}catch(Exception e){
System.err.println(e.getMessage());
}
}

public static byte[] loadFromDB(Connection con, String name){
try{
Statement s = con.createStatement();
ResultSet rs = s.executeQuery("SELECT * FROM classes WHERE name = '"+name+"'");
if (rs.next()){
return Base64Coder.decode(rs.getString("bytecode"));
}else{
return null;
}
}catch(Exception e){
System.err.println(e.getMessage());
return null;
}

}
}

Ezek után következzék a MySQLClassLoader:


package mysqlclasses;

import java.sql.Connection;

/**
* @author balage
*
*/
public class MySQLClassLoader extends ClassLoader {

Connection con;

public MySQLClassLoader(Connection sqlcon) {
con = sqlcon;
}

public MySQLClassLoader(Connection sqlcon,ClassLoader arg0) {
super(arg0);
con = sqlcon;
}

@Override
protected Class< ?> findClass(String name) throws ClassNotFoundException{
System.out.println("Searching for class: "+name);
byte[] data = ClassSaver.loadFromDB(con, name);
if (data != null){
return defineClass(name, data, 0, data.length);
}else{
throw new ClassNotFoundException();
}
}

}

Meglepően egyszerű, nemde? A kipróbálásához létrhozunk pár egyszerű osztályt:

package test;

public interface Test {
public void some();
}


package test;

public class TestA implements Test {

@Override
public void some() {
System.out.println("I'm an A instance.");
}

}


package test;

public class TestB implements Test {

@Override
public void some() {
System.out.println("I'm a B instance.");
}

}

Az egyszerűbb tesztelés érdekében hoztam létre egy Interface-t is, ami fordítás időben ismert, így egyszerűen meghívható a some() metódus. A létrehozott osztályokkat most le kell fordítani, és be lehet írni az adatbázisba:


Class.forName("com.mysql.jdbc.Driver");

Connection con = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "balage", "");

Test a = new TestA();
a.some();
Test b = new TestB();
b.some();

ClassSaver.saveToDB(con, a.getClass().getName(), ClassSaver.getBytesFromFile(new File("bin/test/TestA.class")));
ClassSaver.saveToDB(con, b.getClass().getName(), ClassSaver.getBytesFromFile(new File("bin/test/TestB.class")));

Ezen a ponton érdemes ellenőrizni az adatbázis tartalmát, ahol jól láthatóan szerepel egy “classes” tábla, benne a két osztály bytecode-jával. Ezek után lehet kiovasni onnan őket a következő kóddal (Arra vigyázzunk, hogy a kiolvasandó osztályok NE legyenek elérhetőek a classpath-ban, különben az adatbázis helyett az alapértelmezett ClassLoader fogja őket betölteni!):


Class.forName("com.mysql.jdbc.Driver");

Connection con = DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "balage", "");
MySQLClassLoader loader = new MySQLClassLoader(con);

Class< ?> clsa = loader.loadClass("test.TestA");
Test a = (Test)clsa.newInstance();

a.some();

Ha mindent jól csinálunk, a kimeneten a TestA osztály üdvözlőüzenete elött látni fogjuk a MySQLClassLoader-ben elrejtett kiírást is, ami egyértelműen jelzi, hogy valóban ő olvasta be az osztályt. Siker. Mielött még kikiáltanám a cikk végét, had tegyek pár megjegyzést, ami szükséges lehet a módszer komolyabb használatához:

Jól láthatóan szövegként hivatkozunk a betölteni kívánt test.TestA osztályra. Ekkor felmerül a kérdés, mi van azokkal az osztályokkal, amikre a betöltött test.TestA osztály hivatkozik? Például létrehoz egy test.TestB osztályt, ami ugyancsak az adatbázisból érhető el, és nem szerepel a megadott classpath-ban. A válasz egyszerű. Azokat akkor próbálja betölteni, amikor aktívan használni próbáljuk. Akkor az osztály nevét átadja az alapértelmezett ClassLoader-nek, ami megkeresi a classpath-ban és.. ClassNotFoundException. A probléma ott van, hogy arra már nem a mi MySQLClassLoader-ünket használja. A teendő tehát: alapértelmezetté kell tenni a létrehozott MySQLClassLoader-t, amit megtehetünk az aktuális Thread ismeretében:


MySQLClassLoader loader = new MySQLClassLoader(con);
Thread.currentThread().setContextClassLoader(loader);

Ezen sor után a futásidőben felmerült osztályhivatkozásokat már az általunk megadott ClassLoader-rel fogja betölteni. Kiemelném, hogy ekkor is létezik a MySQLClassLoader szűlője, ami prioritást élvez, azaz mindig az próbálja meg betölteni a keresett osztályt elsőként (persze csak akkor, ha nincs még betöltve).

Még egy probléma: az általunk létrehozot ClassLoader-t csak futásidőben tudjuk használni, a javac fordításkor csak a beépített ClassLoader-t tudja használni, azaz fordításkor minden hivatkozott osztálynak kéznél kell lennie, csak fordítás után lehet az egyes osztályokat bepakolni az adatbázisba. Ami után viszont az adatbázisból hivatkozott .class fájlok törölhetőek a classpath-ból. A programunkat indító osztálynak, és a MySQLClassLoader-nek viszont minden esetben elérhetőnek kell lennie a classpath-ban, ugyanis a java indulásakor csak az alapértelmezett ClassLoader áll rendelkezésünkre.

Végezetül pár hasznos link:

  • [[http://java.sun.com/docs/books/tutorial/ext/basics/load.html]] Egy részletesebb leírás a Java ClassLoader-ek működéséről
  • [[http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html]] A Class metaosztály javadoc-ja
  • [[http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ClassLoader.html]] A ClassLoader osztály javadoc-ja
  • [[http://www.source-code.biz/snippets/java/2.htm]] A Base64 kódolást végző osztály
  • [[http://www.java-tips.org/java-se-tips/java.io/reading-a-file-into-a-byte-array.html]] Egy függvény, ami egy fájlból beolvassa a byte-okat tömbbe

J2EE és JUnit – avagy a platformfüggő Java

Végre, beadtuk. Az UML tárgyból esedékes házi feladatot (lásd még [[J2EE - a nagy aknamező|a múltkori írást]]). Ez J2EE egyszerűen valami félelmetes. Ez a technológia szép. De tényleg…

Az implementáció után mindössze teszteseteket kellett írni az utolsó beadásra. Mindössze. Persze ez akkor sem olyan egyszerű, hiszen azt JUnitban kellett megírni, ami alapvetően maga szeretné futtatni a teszteket. Semmi gond, akkor átverjük, feltöltjük a JUnitot is a konténerbe, és ott majd látni fogja a keresett dolgokat.

Hehe, már megint optimista vagyok ezekkel a cuccokkal kapcsolatban. Ez, hogy feltöltsük a JUnitot, ez körülbelül két óra szívást jelentett a classpath, build path, referenced projects, requirements és hasonló témában projektek és pluginek viszonylatában. Ezek tulajdonképpen mind-mind egyfajta függőséget jelentenek a projektek és más projektek, esetleg libek vagy hasonlók között, de az a poén az egészben, hogy a szerepük között jelentős átfedések vannak. És ami igazán kellemetlen az az, hogy ha a helyes megoldás mellett egy nem szükséges helyen megadod a függőséget, akkor már nem jó. Lehet vele szépen játszadozni.

Jó, túl vagyunk az alapozáson, megvan a teszt keretrendszer, kezdünk teszteseteket írni. Egyszer csak egyik kolléga megkeres, hogy nagyon eszement hibaüzenetet ad egy importra: nem azt, hogy nem találja, hanem azt, hogy nem engedélyezett a használata. Remek, újabb szép körnek néz ki. Ezúttal sajnos nem tévedtem. Némi játszadozás után értettem meg, hogy tényleg látja, csak valami miatt nem akarja használni. Közben szétvertem a tesztkörnyezetet (utána újból órákba kerül, amíg mindenkinél összeáll, de erről később). Na, ekkor némi Google, meg váltogatás a különböző Eclipse környezeteim között (bizony, nekem több is van, be-be-be :) ), és kiderül, hogy a probléma egészen csúnya: az Eclipse támogat egy package-korlátozást (access rule-nak hívja) a különböző pluginekre. Ok, ez önmagában nem csúnya, hisz így az Eclipse-plugin írója rákényszerítheti a felhasználó plugint, hogy az api-n keresztül érje el. De ami gáz, hogy ezt alkalmazta a beépített Java típuskönyvtárra.

Ok, módosítsuk a dolgot. Némi segítség után rájövök, hogy melyik jarban van a keresett osztály. Adjunk hozzá egy engedélyező bejegyzést a jarhoz tartozó access rule-ok közé. Újabb pofára esés, és kiderül, hogy nem írható. Remek. További leírásböngészés, és ekkor kiderül, hogy az ősét, ha tudom szerkeszteni, az is jó. Na, azt tudom, mert a globálisat engedi szerkeszteni, csak a system jarokét nem, meg a workspace-ben definiált pluginekét sem (azokat a plugin.xml szerkesztőjén lehet hakkolni). Remek, beírom az osztálynevet com.sun…. formában, örülnék, hogy megy, de nem megy. Ok, nézzünk mintát, igaza van, /-rel kell írni, és ha *-gal zárom, akkor egy package-re lebontva tudom szerepeltetni. Ok, egy részét átírom /-esre (nem kéne azért a teljes com. tartományt engedélyezni), majd csillaggal lezárom. Még mindig nem jó. Aztán kiderült. Ahhoz, hogy rekurzívan elinduljon lefelé a csomaghierarchiában, ahhoz nem árt **-gal lezárni… Na, ezután már megy.

Illetve csak az a hivatkozás. Csak a libekkel szórakozás miatt elment a futtatókörnyezet. Sebaj, rutinos róka vagyok már, nekilátok és összerakom a megfelelő fájlt (jó, most csaltam, összeklikkeltem a run dialogban). Végre megy nálam. Ekkor töltsük fel svn-re, hogy a többieknek is menjen.

Eltelik pár perc, és kiderült, hogy nem ment át. Mint utóbb kiderült, verzió- és oprendszerkülönbségek miatt. Az OSX->Windows irányban nem működik. És fordítva sem. Az lett a vége, hogy a Windows-osok megcsinálták a környezetet, majd feltöltötték svn-re, ezután én is megcsináltam az enyémet, de én nem töltöttem fel. Erre ezután minden commitnál vigyázni kellett remek. Még szerencse, hogy a Java platformfüggetlen.

De ez semmi ahhoz képest, ami ma hajnali 5 magasságában derült ki, 6 órával a beadás előtt (ameddig persze be is kellett érni az egyetemre). Megírtam már 40 tesztesetet – ez majdnem ezer sor kód, ezek segítségével több hibát is kijavítottam a tesztelt kódrészben. De tényleg. Futott minden. Amikor a kolléga közli velem, hogy a teszteseteim egy része meghal, és ez hazavágja az egész adatbázist. Nálam persze semmi ilyesmi. Némi kísérletezés után kiderül, a gond az, hogy a Windows nem eszi meg a megoldást. Pont. Akkor mutassuk be Macen. De Macen meg egyes Windowson megírt tesztesetek nem futnak. :?

A hibát nem sikerült megoldani… Mindenesetre kezdem azt hinni, hogy olyan, hogy platformfüggetlen nem létezik. A Java legalábbis biztosan nem az. Például az AbevJava máshogy megy Windows-on, mint Linuxon vagy OSX-en. És ez a mostani hiba is megerősíti ezt az elképzelést. Azt, hogy mi lehet a hibás, csak tippelni tudom. Van egy elszúrt (értsd: feleslegesen túlbonyolított) entitáshalmazunk, van egy toplinkünk mysql adatbázishoz csatlakoztatva, van alatta oprendszer, OSGi konténer, stb. stb. stb. Erre már csak Murphyt idézném zárógondolatként:

  1. A bonyolult rendszerek hajlamosak a bonyolult meghibásodásokra.
  2. Ezzel szemben az egyszerű rendszerek is hajlamosak a bonyolult meghibásodásokra.

J2EE – a nagy aknamező

Hát, megvan egy ideje, hogy utoljára írtam. Pedig magamban már többször megfogadtam, hogy rendszeresebben írok. Úgy volna értelme csinálni az egészet, hogy hetente legalább egy bejegyzés születik. Persze ez így hiú ábránd ennyi házi feladat mellett.

Ez az UML házi kész volt. 80 órát egy hét alatt beletolni abba, hogyan kell leimplementálni egy hello world-nél egy szinttel bonyolultabb feladatot J2EE alapon, na ez teljesítmény. És örülök, hogy ennyi idő alatt összeállt…

Nem véletlen tartott eddig. Van benne egy gyönyörű implementált objektumrelációs leképezés, néhány tag elhelyezése, egy xml-fájl és még néhány sor kód megírása után az objektumokat szépen kimenti az adatbázisba, illetve visszaolvassa onnan igény szerint. Tényleg szép. Csak az ember el ne szúrja a tagelést, mert olyan exception-trace-t kap futáskor, hogy öröm nézni. A legnagyobb, amit sikerült kapni, 40 kB méretű volt. Iszonyatosan redundáns, gyakorlatilag az egész háromszor szerepel, az értelmes tartalom másfél-két sor. Szűrd ki…

A fejlesztés során mi RAP-t használtunk GUI-készítéshez. Nem gyenge technológia: Eclipse plugineket AJAX-szal támogatott weblapokra fordít. De azért ezt több projektből összefejleszteni szép teljesítmény. Például nem mindegy, hogy hol kapcsoljuk össze a projekteket. Ha az Eclipse projekt tulajdonságainál fogjuk, és beikszeljük a Referenced projects résznél (hogy szerepeljen a build path-ban), az nem jó. A plugin.xml fájlban kell a depencencies blokkban bejelölni.

Remek, most már lefordul, elindul, és gyönyörű exception trace megint. Most az a baja, hogy nem töltötte be a futás közben a hivatkozott projekteket. Némi szórakozás után kiderült, hogy a megoldás az, hogy még a futtatási konfigurációnál is fel kell venni a hivatkozott projekteket, mint bundle-t. Eredetileg ezt nyersen az xml-be hakkoltam bele, később hívta fel valaki a figyelmemet, hogy a futtatási konfigurációnál is fel lehet venni.

Hasonló szépségek vannak az APIban is. A RAP1.1M1 és az 1.1M3 között megváltozott az alkalmazás belépési pontjának szintaktikája: az M1-ben Display típusú, míg az M3-ban int típusú visszatérési értéket vár. Érdemes megnézni a sorrendet, Display-ből int.

Beletelt némi időbe, amíg rájöttem, hogyan kell megváltoztatni a mintakódot, hogy lefusson. Gyakorlatilag a Display egy azonosítóját kell visszaadni a metódus végén. Szóval minden érdekes.

Hasonlóan jópofa volt az, hogy amikor beraktuk a szükséges webservice meghívásához szükséges fájlokat, akkor kb 25-30 MB méretben kellett jar-fájlokat a lib könyvtárba tenni. Ami problémássá teszi a dolgot, hogy ez csoportmunkában készült házi feladat, azaz fel kellett tölteni egy svn szerverre, és a többieknek le kellett szedni. Hab a tortán, hogy az svn csak fájlok között frissíti a status bart, így a 10 megás jarnál úgy néz ki a dolog, mintha meghalt volna menet közben. A csúcs az volt, amikor ezt upload közben sikerült valakinek fagyásnak értelmeznie, és kilőtte az Eclipse-et. Ezután egy órába került, amíg sikerült rendbe tennie a rendszert…

Érdekes ez az Enterprise Java technológia. Ekkora aknamezőt még nem láttam… Elég valami apró hiba, és hihetetlen mennyiségű hiba bukkan fel, és a hibaüzenetekből is alig lehet kikövetkeztetni, hogy mi lehetett az ok. Elég bonyolult architektúra, rengeteg 3rd party lib, és nagyon korlátozott tapasztalat: ez elég ahhoz, hogy a nem túl bonyolult feladat megoldását nagyon megnehezítse.

Java kimenet UTF-8 kódolásban

Csalódtam a rendszeremben. Pár nappal ezelöttig abban a szent meggyőződésben voltam, hogy a Kubuntu tetőtől talpig UTF-8 kódolással dolgozik. Nos ez többnyire igaz. A java VM esetén az stdout alapértelmezett kódolása latin-1, ami normális esetben nem tűnik fel. Önálló labor feladatom során merült fel, hogy egy java program kimenetét kellett böngészőben megjeleníteni. A program bemenetként egy UTF-8 kódolású XML fájlt kapott, fel sem merült bennem, hogy gond lehet a kódolással.

Meglepetésemre a program kimenetén minden ékezetes karaktert szorgalmasan kicserélt egy-egy kérdőjelre. Néhány óra bogarászás és kutatás után kiderült, hogy a Java belső kódolásként [[http://hu.wikipedia.org/wiki/UCS|UCS]]-t használ, minden bemenetet erre konvertál, és ebből alakítja át a kimenetet a megfelelő kódolásra.

További kutatással sikerült egy egyszerű módot találnom, amivel beállíthatom a sztandard kimenet kódolását. UTF-8 beállításához a következő néhány sorral kell kezdeni a main() függvényt:


try{
PrintStream out = new PrintStream(System.out,true,"UTF-8");
System.setOut(out);
}catch(Exception e){}

Rövid magyarázat: a PrintStream osztály egy egyszerű szűrőként dolgozik, ami a bemenetét UTF-8-ra átkódolva adja tovább a megadott Stream-re (jelen esetben a System.out). Ezután beállítjuk a létrehozott Stream-et alapértelmezett kimenetként. Voilá. Minden további kimenet UTF-8 kódolású lesz.

Google Calendar szinkronizálás naptárprogrammal

Az elmúlt időszakban a többiekkel gyakran kellett időpontokat egyeztetnünk különféle ügyek miatt, és felmerült az ötlet, hogy legyen a zárt használatú wikirendszerünk mellé naptárrendszerünk is.

Az első ötlet egy php script alkalmazása lett volna, ami képes megfelelően kezelni pl. az ics fájlokat. Találtunk is ehhez használható scriptet, de bugzott. Ehelyett végül is az egyszerűbb megoldás mellett döntöttünk, és elkezdtünk Google Calendart használni.

Ez egy szép és jó szolgáltatás, de valahogy (számomra legalábbis feltétlenül) kényelmetlen volt a használata, jobban örültem volna, ha az asztali levelező (és címjegyzék, stb.) kliensemhez szépen csatlakozó naptárprogramot használhatok.

Ehhez a Google azt a segítséget nyújtja, hogy ad ics-linket a naptárhoz, amit be lehet tölteni a kliensprogramba. Ez mind nagyon szép és jó, de események felvétele kapcsán nem ad támogatást a kliensprogramokhoz (pedig erre is van tulajdonképpen szabványos megközelítés, a nyílt forrású szoftverek között is. A csak olvasható hozzáférés meg kényelmetlen…

De az is lehetséges, hogy ics-fájlt importáljon az ember az online naptárba. Igen, migrációt támogat, viszont azt, aki kliensprogrammal veszi igénybe a szolgáltatásokat, nem. Feltehetőleg azért, mert így nem nézik meg a Google reklámjait, esetleg nem kezdik el használni a további szolgáltatások
Hát, fogtam magamat, és beütöttem a Google-be a problémámat, és adott egy fizetős (15$/év) szoftvert, ami képes kétirányú szinkronizációra. Nem nevezem meg, pláne, mert nem is éri meg az árát, ha az ember hajlandó egy kicsit szórakozni a dologgal.

Egy későbbi keresésnél viszont találtam egy Javaban íródott (és tényleg crossplatform) scriptet, ami megoldja a gondot olyan kliensprogramokkal, amik ics-fájlba mentik (tudják menteni) a fájlokat – ilyen az Apple iCal programja OSX-en (naná, eredetileg ennek a formátuma volt a mostanra kváziszabvánnyá vált ics), a legtöbb Linuxos naptárprogram, Windowsra pedig meg lehet próbálni a Mozilla Sunbird programját – esetleg a Thunderbird-del egybecsomagolt változatát, a Lightninget (figyelem, ez még csak a 0.5-ös verziónál tart, azaz nem stabil változat!). Outlook (Express) felhasználók így jártak…

Ez a script a GCalDaemon, és teljesen használható a fent említett célra, és mellesleg néhány egyéb információt is ki tud nyerni a Google accountból. A telepítését nagyon részletes dokumentáció, és most már GUI is segíti, ezért ezzel nem foglalkozom.

Viszont a script működése megér pár szót még: a kiens gyakorlatilag HTTP-kérésekkel importáltatja a Google Calendarba a helyi gépen megváltozott fájlt, és a privát ICS URL-en keresztül lehúzza, ha ott megváltozott, ezzel téve lehetővé az egyszerű szinkronizációt. Igen, ezért szeretjük a nyílt protokollokat…