A .hgrc-mbe egyretöbb extension szivárog be:

[extensions]
hgshelve=/home/elek/satupad/hgshelve/hgshelve.py
hgext.fetch=
hgext.rebase=
hgext.graphlog =
transplant =
hgext.color =
hgext.purge =
hgext.mq =

Az egyik legújabb játékom az MQ extension. Nagyon nagy vonalakban arról van szó, hogy a rendes changelog tetején még ül egy rakás patch (konkrét patch fájl gyűjtemény egy könyvtárban), amik bár külön álló fájlok, az mq extension a saját parancsaival úgy kezeli, mint a hg changelogon szánkáznál időben előre és hátra.

Két tipikus használata van. Egyrészt el lehet játszani, hogy pullozok regy public repositoryból, és csinálok néhány patchet. Amikor frissítik a public repositoryt, akkor a patcheken időben visszalépkedek, ekkor changesetek helyett csak patch fájlok lesznek belőlük, pullozok egyet, és megint előre lépkedek és applyolom a patcheket.

(Ez így leírva kicsit bonyolultnak tűnik, de ki kell egyszer próbálni, és akkor érthetővé válik, én se nagyon értettem, amíg nem kezdtem el használni.)

Egy másik felhasználási mód, amikor szerkeszteni akarok egy commitot. Ilyenkor convertálom a changeseteket patchekké, a patch fileban szerkesztem (akár a commit message-t is), majd vissza konvertálom a patch changeseteket rendessé. Természetesen fizikailag ezek már más changesetek lesznek, tehát nem érdemes akkor próbálkozni ezzel, ha már pusholtuk is a changeseteket.

És most a probléma. Alapvetően ezt csináltam

1. leszedtem az aspectj maven plugin-t svnből és egy svn hg bridge-en keresztül hg-be konvertáltam
2. csináltam hozzá néhány patchet, hogy kicsit jobban működjön

A patchet ilyenkor a .hg/patches alá kerülnek. Akinek ott vannak a patchek alatt az én fájljaim az tudja buildelni az én változatomat, kinek nincs, az nem. Mivel azt akarom, hogy más is lássa a változtatásokat, ezért a hg qinit -c parancsot használtam, ami a .hg/patches-ben inicializál egy másik hg repót, ahol verziózza a patcheket. (E nélkül a patchek csak nálam lokálisan lennének meg).

A proléma az, hogy a .hg/patches repó természetesen egy másik repó, mint ami a fő kódot tartalmazza, és innentől kezdve egy rendes buildhez (pl. a Hudsonon) nem elég hg clone-t mondanom, hanem a hg clone után még a .hg/patches-hez egy másik hg clone is kéne, amit ugye a Hudson nem fog megcsinálni nekem.

Azt csinálhatnám, hogy a patcheimet átalakítom rendes changesetté, csak ezt meg pont nem akarom, mert akkor elveszik pl. a patch neve mint információ, meg a következő SVN frissítéskor kicsit bonyolult lenne a helyzet.

Nem találtam jobb nevet erre, mint a JPA 2.0 zsargonjából kölcsönzött Metamodel kifejezést, de talán egy példán keresztül világosabb lesz, mire gondolok. Tegyük fel hogy szeretnék egy Java Bean to Java Bean mapper-t, hasonlót a dozer-hez, csak egyrészt programmatikusan szeretném konfigurálni (nem XML-ből), másrészt én akarom részletesen megmondani, hogy mit másoljon, és csak azt másolja, amit szeretnék.

Tegyük fel, hogy van egy managed JPA entitás struktúránk, amiből szeretnék egy detached változatot, de úgy, hogy én mondom meg, hogy az egyes objektum kapcsolatokból melyik legyen kifejtve és melyik ne. Ezt a vázolt mapper alkalmazással fogom elérni, belemondom, hogy melyik atribútuomkat másolja, és egy adott entitásból egy ugyanolyan detached állapotú osztályhierarchiát másol.

Hogy mit másol, azt megadhatom mondjuk Expression Language szerű kifejezéssekkel. Pl.:

1
2
3
4
5
6

Mapper<Partner> m = MapperFactory.create(Partner.class);
m.config("partner.nev");
m.config("partner.cim.varos");
Partner managed = ....
Partner detached = new Parner();
m.copy(managed,detached);

És itt szeretném elérni azt, hogy a 2. és a 3. sorban típusosan adhassam meg a másolási szabályokat.

Jelenleg két ötletem van erre:

APT

Az első az, amit a JPA2.0 is alkalmaz. Generálunk meta osztályokat mondjuk PartnerMeta, CimMeta, stb.néven, és azokba begeneráljuk a típusok leírását. Pl.

1
2
3

Mapper<Partner> m = MapperFactory.create(Partner.class);
m.config(PartnerMeta.nev);
m.config(PartnerMeta.cim.varos);

A JPA2 mondjuk Partner_-nek hívná metamodel osztályt, és nem lenne rekurzív, tehát a Partner_.cim az nem egy Cim_ a JPA2-ben, ezért a fenti definíciót nem is tudnánk használni. Persze nem egy ördöngősség saját metamodelt kitalálni és az APT eszközzel viszonylag elegánsan lehet generálni ezeket az osztályokat (már ha beszélhetünk eleganciáról bármilyen generált kód esetében): Elég egy jól irányzott jar-t elhelyezni a fordítás idejű classpathba és már generálódnak is az osztályaink (lásd még SPI).

A JPA2 API-ját még nem használtam, de azért idemásolom az íze kedvéért egy cikkből, hogy hogy megy ez:

1
2

Root<Team> team = cq2.from(Team.class);
cq2.select(team.get(Team_.name)).where(cb.like(team.get(Team_.name), "Longfellow%"));

cglib

A másik megoldás a futás idejű byte-code generáláshoz vezet. Ezt csinálja pl. a liquidform:

Person p = LiquidForm.use(Person.class, "p");
List people = em.createQuery(
    select(p).from(Person.class).as(p).where(like(p.getSurname(), "Smith%")).toString())
    .getResultList();

és a Mockito:

Partner partner = mock(Partner.class);
when(partner.getNev()).thenReturn("valami");
assertEquals("valami",partner.getNev());

Látható, hogy egyes függvények paraméter gyanánt egy függvényhívást kapnak (pl. partner.getNev()) és nem a függvény hívás visszatérési értéke az érdekes, hanem maga a hívás, mintha egy metamodel egy elemét adnánk meg.

De hogy lehetséges ez? Nem tudom megállni, hogy ne idézzem a Mockito szerőjét Szczepan Faber-t:

…I was asked if Mockito is able to mock concrete classes? The answer is yes, Mockito doesn’t care if you mock an interface or a class. Mockito can do it thanks to primordial voodoo magic only ancient shamans understand these days (you guessed right – it’s the cglib library).

A cglib egy futási idejű bytecode generátor, ami az ASM nevű bytecode manipulátort használja. Gyakorlatilag proxy szerű objektumokat tudunk vele létrehozni, amire mi mondhatjuk meg, hogy az egyes metódusok mit csináljanak. Mindkét megoldás úgy kezdődött, hogy csináltunk egy saját Partner osztályt a Mockito.mock vagy Liquidbase.use factory-val. Na ez az osztály már nem egy rendes Partner, hanem a memóriában összerakott saját bytecode-ból áll.

A mockito ebbe a bytecode-ba azt írja bele, hogy egy ThreadLocal polcra tedd el az adott hívás tényét (pl. partner.getNev meghívodott). Aztán a when metódus már meg se nézi milyen paramétert kapott (partner.getNev() visszatérési értékét), hanem erről a polcról megnézi, hogy épp mi futott le, és ezért már tudja, hogy amikor a mockolt osztályon legközelebb meghívódik a getNev(), akkor mit kell visszaadni. (A when metódus természetesen később hívódik meg, mint a partner.getNev(), mert előszőr a when argumentumait kell kiértékelni).

A liquidform ennél kicsit egyszerűbbet utat választott. A partner.getNev() meghívásakor ő is feljegyzi, hogy milyen hívás történik éppen, és visszaad egy visszatérési típusnak megfelelő objektumot, de előszőr egy globális Map-ben a kettőt összerendelni. A like(p.getNev(), “Smith%”) metódust ezért érdeklik a visszatérési értékek, mert ez alapján megkeresi, hogy a Map-ben van-e rá bejegyzés, és ha van, akkor onnan kimatekolja, hogy a p.nev értéket kell berakni majd String szinten a készülő Querybe.

A liquidform megoldásának azonban van egy nagy hátránya: nem tud primitív típusokat kezelni. Mivel a Map-ben létező objektum referenciákra tudja megmondani az elérési utat, ezért egy visszaadott long értékkel nem tud mit kezelni. Persze meg lehetne a liquidformot is okosítani a Mockito módszerével, de akkor egy másik problémába ütközünk. A like(p.getNev(), “Smith%”) híváskor a polcon az szerepel, hogy egy pszeudó hívás érkezett a bytecode lekvárunkba, aki ezt gondosan feljegyezte. Majd ez után kapunk két String paramétert. Hogy melyik String paramétert kell feloldani a polcunkon lévő hívási információból, azt csak akkor tudnánk megmondani, hogy ha egy kitűntetett String értéket lefoglalnánk annak a jelzésére, hogy az a visszatérési érték nem számít, ehelyett használd a polcon lévő hívási információt. Másik lehetőség, hogy ha a paraméterek minden esetben felcserélhetők, akkor azt mondjuk, hogy a metamodeles hívás mindig az első kell, hogy legyen.

Hát itt tartok éppen a gondolataimban.

A regény eleje táján derül ki az az alapfelállás, hogy egy távoli bolygón éppen robotok dolgoznak. A robotok jól specializáltak: van amelyik energiát tud termelni, van amelyik űrkutatásokat végez, van amelyik szöveget elemez, van amelyik koordinál. Minden robot rendelkezik alrobotokkal, akik a nagy robotnak az inteligens karjai, az adott területért felelős központ irányítja őket (és persze közvetve a koordinátor). A robotok nagyon jól tudnak alkalmazkodni a környezetekhez, szép lassan agy előre írt program szerint kifejlesztik a gyártó sorokat és a technológiát, hogy eljussanak az űrön keresztül a szomszédos bolygókra.

A sztori persze folytatódik tovább, ami engem lenyűgözött, az az egész programozása. Egyszerűen annyira jól működik a dolog, hogy rögtön arra gondoltam, hogy jó lenne egy ilyet leprogramozni.

Valamikor a kilencvenesek években lehetett még, amikor a bátyám egy háziján keresztül ismerkedtem meg valamelyik egyetem projektjével, ahol Java focicsapatokat kellett programozni, majd ezek vívtak meg egymással. A játékosok egy interfacen keresztül látták a tér egy bizonyos szegletét, tudtak hanggal kommunikáli, és persze volt egy futtató környezet, ahol össze mérhették a tudásukat.

Most keresni kezdtem, de már nem nagyon találtam ennek a bajnokságnak. Csak a robocode-ra találtam rá, ahol tankokat kell irányítani egy térben (ahogy néztem a robocode nagy kalsszikus, sajnos nekem ez is kimaradt eddig), és aztán pont másnap olvastam egy versenyről hasonló témában. (El is kezdtem nézegetni, de most úgy látom, hogy a februári leadásig nem nagyon lesz már időm).

Jó lenne egyszer valami kis hazai háziverseny valami hasonlóból. És jó lenne egyszer komolyabban megismerkedni a neurális hálókkal, genetikus algoritmusokkal, és valami éles alkalmazást írni.

És valószínű ennek a folyománya az, ami rendszeresen szembe jön, egy exception (hová is lenne az életünk exceptionök nélkül), ami valahogy így néz ki:

Caused by: com.db4o.ext.InvalidSlotException: id: 5182
        at com.db4o.internal.marshall.UnmarshallingContext.invalidSlot(UnmarshallingContext.java:81)
        at com.db4o.internal.marshall.UnmarshallingContext.read(UnmarshallingContext.java:49)
        at com.db4o.internal.ObjectReference.read(ObjectReference.java:281)
        at com.db4o.internal.ObjectReference.read(ObjectReference.java:267)
        at com.db4o.internal.ObjectContainerBase.getHardObjectReferenceById(ObjectContainerBase.java:956)
        at com.db4o.internal.marshall.AbstractReadContext.classMetadataForObjectId(AbstractReadContext.java:85)
        at com.db4o.internal.marshall.AbstractReadContext.readObject(AbstractReadContext.java:57)
        at com.db4o.internal.marshall.AbstractReadContext.readAtCurrentSeekPosition(AbstractReadContext.java:46)
        at com.db4o.internal.OpenTypeHandler.read(OpenTypeHandler.java:172)
        at com.db4o.internal.Handlers4.readValueType(Handlers4.java:313)
        at com.db4o.internal.marshall.AbstractReadContext.readAtCurrentSeekPosition(AbstractReadContext.java:48)

És így tovább.

A hiba teljesen kiszámíthatatlanul, ugyanakkor jól reprodukálhatóan előjön. Pl. előveszek egy backup db4o file-t, megnyitom, teszek-veszek benne, lezárom az alkalmazást. A következő megnyitáskor már nem nyílik meg az adatbázis. Ha viszont ugyanazt a cselekmény sort újra végigviszem az elmentett db4o file-on ugyanúgy elszáll.

Tehát előszőr is ki kéne dobni a db4o-ból a BigDecimal-okat, amihez át kéne konvertálni a sémát. (Tegyük fel, hogy egy számlázó programban sosem fogok beleütközni a float korlátaiba). Ha nincs több BigDecimal mezőm, akkor használhatom a stabil db4o változatot. A másik meg, hogy szükségem lesz egy dump file formátumra. Egyrészt mivel féltem a már bent lévő adatokat, másrészt mert a mező típus konvertálás is nagy szívás egy meglévő db4o adatbázison, az egyik legegyszerűbb megoldás, hogy kidumpolom az adatbázist, majd típus refaktor után vissza.

Mi legyen a dump formátum. Kapásból a JAXB és Json jutnak eszembe, de ezek ahogy én tudom nem támogatják a referenciák kezelését. (Ha az objektum fában többszőr is előfordul ugyanaz az objektum, akkor visszatöltés után ne két, hanem csak egy objektum legyen, amire két helyről mutat referencia.

És itt jön kébe a YAML, amit pont tudja mindezt.

Előszőr a jYaml-t próbáltam, ami alapból egyszerűen működik, de régóta nem fejlesztik, és túlságosan is elnézően bánt a Yaml fájl hibáival. Aztán jött a Snakeyaml. Ez már tette a dolgát mint a kisangyal.

Objektum mentése:

Yaml yaml = new Yaml();
yaml.dump(eztmentemel, new FileWriter(file));

Objektum betöltése:

Yaml yaml = new Yaml();
DatabaseBackup backup = (DatabaseBackup) yaml.load(new FileInputStream(file));

Maga a Yaml file meg valahogy így néz ki.

!!net.anzix.nona.entity.DatabaseBackup
felhasznalok:
- email: geza@hutira.net
  partner: &id001
    partnerek:
    - &id005
      partnerek: []
      szamlak: []
      torzs: {adoszam: null, bankszamlaSzam: null, nev: Asztal kft., szamlaCim: Sötét út 20.,
        szamlaIrsz: '1111', szamlaVaros: Budapest}
      tulajdonos: *id001
....

Itt már rögtön látszik is a referencia kezelése. A partner objektum instance azonosítója id001, és a partnerek listában található egyik partner tulajdonos mezője pont erre mutat vissza referenciával.

Mivel a db4o-val egy paranccsal elmenti az objektumfát, ezért 3 sorban tudok backupolni és visszatölteni a backupot, és a yaml file-t minimálisan módosítgatva (segít a nagyerejű grep parancs) még a típus konverziókat is sikerült viszonylag kis fájdalom árán meglépni.

Yaml a mi barátunk.

Persze igazából egy stack trace megosztó social site lenne jó. Napi exception, hasonló exceptionnel barátkozó fejlesztők, ismerős exceptionok bejelölése, stb.

Amíg a nagyra törő álmok megvalósulnak, addig is itt egy kategória, ahová mintegy ilusztárcióként feltöltök egy-egy szép darabot.

javax.ejb.EJBException: The bean encountered a non-application exception; nested exception is:
java.lang.reflect.UndeclaredThrowableException
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:358)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:286)
at $Proxy54.existsValami(Unknown Source)
at hu.xxx.xxx.xxx.ValamiServiceV1X0Test.testExistsValami(ValamiServiceV1X0Test.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
Caused by: java.lang.reflect.UndeclaredThrowableException
at $Proxy55.getEM(Unknown Source)
at hu.xxx.xxx.xxx.ValamiServiceV1X0.queryValamiFind(ValamiServiceV1X0.java:52)
at hu.xxx.xxx.xxx.ValamiServiceV1X0.existsValami(ValamiServiceV1X0.java:64)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:158)
at org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:141)
at org.apache.openejb.core.interceptor.InterceptorStack.invoke(InterceptorStack.java:122)
at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:221)
at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:174)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217)
at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:281)
... 30 more
Caused by: java.io.NotSerializableException: org.apache.openejb.persistence.JtaEntityManager
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.copyObj(BaseEjbProxyHandler.java:501)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.copy(BaseEjbProxyHandler.java:301)
at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
... 45 more

(Élesebb észrevehetik, hogy egy maven által futtato junit tesztből próbálok standalone összerántani egy EJB konténert OpenEJB-vel, hogy konténeren kívül futtathassam az integrációs teszteket. Egyelőre kevés sikerrel)

Az első tapasztalatok:

1. Nem árt tudni, hogy GPL, tehát az über titkos üzleti alkalmazásban nem használhatom.
2. Érezhetően gyors. Mondjuk iszonyú kis adatbázisom van, gondolom jól betölti az egészet a memóriába.
3. Az API-ja csábítóan egyszerű. Queryket írni annonymous-inner-class-okkal igazi fényűzés.
4. Cascade-ra ugyanúgy gondolni kell. Objektum lekérésnél alapból 5 mélységű a rekurzió, de update/store-nál default nincs rekurzió. Eltartott egy ideig míg rájöttem, miért nem megy rendesen. A rekurzió szintje állítható teljes adatbázis, entitás és mező szinten is. Csak kérni kell.
5. A séma változásra ez is érzékeny (különösen, ha az objektum hierarhia változik)
6. A managed-detached objektumokra ugyanúgy figyelni kell. Amíg nem sikerült összeraknom számos esetben elszabadultak az objektumok, és megsokszorozódtak. (Csak egy oc.store() metódus van, és ha detached-et akarok updatelni, akkor lelkiismeret furdalás nélkül létrehoz új objektumot.)
7. Alapból tud olyat, hogy minden objektumnak van ID-ja (van UUID-ja is, de az nem kellett). Ebben az a furcsa, hogy az ID egy belső dolog, és nem az entitásban van tárolva, hanem API-ból lekérdezhető: kedves konténer, ennek a managed objektumnak mennyi az ID-ja? Az viszont nem meglepő, hogy egy detached objektumnak már nem lehet elkérni. Talán van valami merge itt is, de még nem találtam meg. Igaz nem is nagyon kellett, mert a Wicket detachable modeljei pont tudják azt, hogy az ID-t eltárolják, amíg még managed az entitás, és az alapján visszatöltik, amikor kell.
8. Nagyon barátságosan tesztelhető, mert egy statikus függvény meghívásával át lehet az egészet in-memory db-re állítani. Onnantól kezdve csak iniciaálizálni kell benle pár adatot, és mehetnek az integráiós(abb) tesztek.
9. Constraintek Java API-ból adhatóak meg. A Bean Validation Frameworkot valószínű 5 sorból be fogom tudni kötni.
10. Nincs jó felület, ahol meg tudom nézni a tartalmát, és alap szerkesztéseket tudok végrehajtani. Egy BeanShell-t próbáltam már rá állítani, de még nem sikerült összelőni.
11. Elég jó doksija van, pedig még csak főleg a tutorialt olvastam, a reference manualnak csak a részeit.
12. Érdekes következménye van annak, hogy minden objektumot el tud menteni. Pl. a JPA-ból kiszelektált csoda objektumokat nem érdemes rögtön elmenteni, mert előhúzás után a lazy mezők rosszul fogják érezni magukat. Ugyanígy a BigDecimal serializálása alapból nem triviális, ennek a kezelésére külön kiterjesztést kell bekapcsolni (bekapcsolt kiterjesztéssel szerkesztett db fájlt olvasni legközelebb szintén csak bekapcsolt kiterjesztéssel rendelkező konténerrel lehet).

Szóval egyelőre barátok maradunk és bent marad. Még meg kell nézni a tranzakciókat, a Bean Validation Frameworkot bele reszelni, és majd byte[]-el kell még tesztelni.

Ha wicketben elnavigálunk egy statfull oldalról, akkor azt a keretrendszer leserializálja és elrakja. Ha az új oldalról mondjuk a backkel visszamegyünk, akkor az előző oldal példányt vissza serializálja és azt rendereli le. Ha azonban a serializálás közben egy nem serializálható mezőt talál az oldal objektumon, akkor dob egy kivételt (nem a felületen, csak az alkalmazás szerver logjában), és amikor vissza akarunk térni, már csak egy Page Expired oldal fogad.

A Wicket és az IoC kapcsolódási pontja az IComponentInstantiationListener osztály. A beregisztrált listenerek minden komponens létrehozásakor meghívódnak a Component osztály konstruktorában. Mivel a leszármaztatott komponensben első lépésben meghívjuk a szülő osztály konstruktorát, ezért ha egy beregisztrált guice-os listener injektál az annotált mezőkebe, akkor azoknak értéke már a konstruktorban elérhető lesz. Ilyen okos konstruktor, azonban csak a Component osztályban van, a Model-ek és DataProviderekben nem.

Van még egy másik dolog, amire épül a Wicket, hogy a Model-ek egy jó része Detachable, azaz az oldal elrakásakor nem serializálódik úgy ahogy van, hanem csak a fontos mezők kerülnek elmentésre (hogy mi fontos, azt mi implementáljuk). Ezzel csökkenthető az oldal állapotok által elfoglalt hely nagysága. Tipikusan pl. ha egy model egy JPA entitást tárol, akkor elég elrakáskor a primary key-t elrakni, és amikor a komponens fát előhúzza a wicket, akkor az Id alapján újra betölti az entitást az adatbázisból.

Már ha éppen kéznél van a Modelben egy EntityManager. ServiceLocator.getInstance() típusú trükkel mindenhol kéznél lehet, de IoC-vel már bonyolultabb a probléma, mert az EntityManager nem serializálható, és a jól beinjektált objektumot nem tudja elserializálni a wicket. Ha meg transient, akkor a Modelt el tudja serializálni, de elővétel után az EntityManager helyett egy nagy null lesz, mert elővételkor nem fut le a Listener, hogy injektáljon.

Mi a megoldás? A wicket-guice azt csinálja, hogy egy un. LazyInitProxy-t használ. Ez a nevének megfelelően egy olyan proxy, ami az első híváskor inicializál a hasába egy adott osztályt, amihez majd híváskor proxyzza a kérést. A wicket-guice amikor a Component-ekbe kéne injektálnia, nem az Guice-os Injectort használja, hanem kézzel végig szánkázik a potenciális injektálandó mezőkön, és ahová injektálni kell, oda ő injektál egy proxy-t, amibe belírja a cél mező típusát és a rajta lévő annotációt. A proxy tehát tudja ezt a két értéket, ami már elég kulcs, hogy szükség esetén ez alapján az Injectortól elkérje a megfelelő példányt, aminek tovább kell adni a kérést. És persze a csak mező és annotáció típust hordozó proxy szerű objektum vidáman serializálható.

Ezzel a trükkel a Component szinten lévő @Injectálandó szolgáltatások helyére egy speciális serializálható referencia kerül. Viszont az ily módon beinjektált osztály által hivatkozott szolgáltatók már hagyományos Guice IoC szinten jönnek létre.

A megoldás tehát az, hogy a Page-ekbe rakunk @Inject-eket, és a Modelek és DataProviderek megkapják konstruktor paraméterbe a beinjektált szolgáltatásokat, hiszen mi tudjuk, hogy első szinten azok serializálható visszatölthető referenciák.

PS: kitakarítottam a commentek közül az 500 spamet, találtam három értékes kommentet (miért nem kaptam róluk emailt??), amire mindjárt válaszolok. kicsit újra rendet raktam itt. Jól megült itt a por, mióta utoljára itt jártam.

Az első követelményt szinte minden JPA provider tudja, a második viszont már keményebb dió. Az Eclipselink pl. csak a drop-and-create szolgáltatást ajánlja, azaz törli az összes táblámat, és újra létrehozza a sémát, még akkor is, ha csak egy új mezőt, vagy egy új táblát hoztam létre.

Az openjpa viszont még az én igényeimet is kielégíti. Erre egyrészt ad egy Java osztályt, de van hozzá Maven plugin is. Megnézi az entitásaimat és tud generálni belőle create DDL-t, illetve refresh-t is, azaz egy meglévő adatbázishoz képest a különbséget. Az adatbázis kapcsolatot a persistence.xml-ből veszi, vagy konzol paraméterből is megadható. Az SQL parancsokat kiírja fájlba, vagy rögtön frissíti/létrehozza az adatbázist is. Elvileg ugyanerre be lehet konfigurálni a Persistence Unitot is, de azt még nem próbáltam ki.

Az első próbák ígéretesek. Új oszlopot, táblát felvesz anélkül, hogy a többit törölné. Ha mezőt törlök, akkor persze nem törli a megfelelő mezőt, de ezt akár tervezési döntésnek is be tudhatjuk.

Nekünk volt erre egy sufni toolunk régen, ami felépítésében sokat ígérő volt, de persze a JPA-ból csak a triviális dolgokat implementáltuk, most viszont ez úgy tűnik el lehet dobni, mert az openjpa jó lesz minderre. Lehet hogy providerként is megpróbálkozom vele.

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.

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.