internet updater

Szeretnék egy standalone Swing alkalmazásban internetes software update lehetőséget tenni. (Illetve csak érdekel, hogy lehetne megoldani.)

Hiába túrom az internetet, seholse találom, hogy lenne rá előre kész megoldás. Van a web start, de nekem nem az kell. Tudom, hogy a JVM magát tudja, de nekem az se jó. Más találat nem érkezik.

Az egyetlen megoldás eddig amit találtam, hogy Eclipse vagy NetBeans platform alá vonulok, de én ennél pehelysúlyubb megoldást keresek. Esetleg látott már valaki ilyen frameworkot?

JSF (IoC)

Az IoC-s huhogásom visszavonva, megtaláltam rá a megoldást. A faces-config.xml-ben vidáman lehet egymásra hivatkozni a beanekkel:

   <managed-bean>
        <managed-bean-name>RecipeAction</managed-bean-name>
        <managed-bean-class>recept.RecipeAction</managed-bean-class>
        <managed-bean-scope>request</managed-bean-scope>
        <managed-property>
            <property-name>recipe</property-name>
            <value>#{recipeDTO}</value>
        </managed-property>

    </managed-bean>
    <managed-bean>
        <managed-bean-name>recipeDTO</managed-bean-name>
        <managed-bean-class>recept.RecipeDTO</managed-bean-class>
        <managed-bean-scope>request</managed-bean-scope>
    </managed-bean>

Azaz a RecipeAction recipe metódusába a setteren keresztül szépen belemegy egy recipeDTO (mivel request scope, ezért mindig újra létrejön egy új és azt rakja be).

Lesz ebből még valami.

JSF (part 1)

A napi adag mellett végre talán megint lesz egy kis időm tovább nézni a JSF-t, de előtte gyorsan leírom az eddigi tapasztalatokat:

A kontextus: azt mindenhol mondják, hogy a JSF szép fastruktúra, a web komponensek hasonlóan felépítenek egy fát, mint mondjuk a Swing-ben. Adatok beküldésekor, validálásakor, rendereléskor, minden node a saját részét csinálja meg. Ami nekem új volt, hogy a másik alapvető dolog, hogy vannak POJO bean-ek (xml-ben definiálva, hogy application, session vagy request scope-pal működnek.) Ezeknek a bean-eknek az egyes attributumait (de néha a függvényeit is) hozzá lehet rendelni a fa komponenseihez. (Tipikusan mondjuk formhoz). Ez az EL-hez hasonló szintakszissal megy, csak $ helyett #-el.

Pl. meg lehet csinálni, hogy egy form mögé rakok egy bean-t, és submit-kor az egész bean kitöltődik a request adatokkal. Rögtön tehetem session scope-ú bean-be is, és akkor már is elraktam a session-ba a bemeneti adatot (persze a validálás után).

Minták: A gond nálam ott bonyolódott el, hogy bármelyik form bármelyik eleméhez lehet bindelni. Ezzel nagyon szép kaotikus dolgokat lehet csinálni. Én pl. szívesen tanulmányoznék néhány mintát, hogy hogy lehet viszonylag normálisan összekötögetni a dolgokat, hogy valamiféle szétválasztása a rétegeknek megmaradjon.

IoC Ehhez kapcsolódik, hogy nekem, aki a Spring IoC konténerén szocializálódott, egy kicsit kaotikus volt. Egyrészt, hogy minden bean-t össze drótozunk minden formmal, másrészt, hogy a a beanek is egymással statikus gyártófüggvény szerű dologból lekérhetőek. Nem tudom miért nincs benne egy kicsit több IoC szellem. Talán meg kéne néznem a Spring integrációt is.

A doksi: az apit és a taglibrary doksit nézegettem, de néha elég nehéz volt kideríteni belőle dolgokat (pl. hogy működik a dataTable). Aztán most nézem a speckót, úgy tűnik az én hibám, mert teljesen más helyen kellett volna kereseni. Azért sokat segítene egy almanac szerű oldal.

ui: ja és semmi Creator csak Netbeans, ez nagyon fontos

Folyt köv.

Session cookie

Jó dolog ez a jcp igazán, szórakozásnak se utolsó olvasni a specifikációkat és a szavazásokat. Hanem az kezd igazan jo lenni, amikor kevésnek bizonyul speckó.

Pl. szeretnék olyan session-t, ami megmarad 1 napig, mégha a böngészőt be is zárom. Ezt nem tudom (eddig nem sikerült) megcsinálnom. A session cookie ugyanis Expired kitétel nélkül jön le, tehát addig él, ameddig a böngészőmet bezárom. (Legalább is ez a tapasztalatom. A 2.4-es Servlet speckóból semit sem találtam az ügyre vonatkozóan).

A session cookie-t nem lehet lekérdezni az apival (bár gyártó függő csomagok néha vannak, de azt ugye azért mégsem). Tehát nem marad semmi eszközöm arra, hogy befolyásoljam a session cookie életét.

Előszőr arra gondoltam, hogy valami Listenerrel megfogom a requesteket, és amikor új session(isNew) van, akkor megfogom a cookie-t. De hamar rajottem, hogy ehhez a request (amibol a session jön) es a response (amibe a cookie-kat dobaljuk) is kell.

Akkor jott a filter. Ott megvan mindkettő, de tüzetesebben vizsgálva szembeötlő, hogy a Cookie-kat csak befele dobalni tudom lekérni egyáltalan nem. Na erre hamarabb is rájöhettem volna.

Akkor csinálok egy HttpServletResponseWrapper-t a filterben es azt adom tovább a chain-nak és a setCookie metodusaban árgus szemekkel figyelek: ezt is hiába, mert semmi nem törtenik. Valószinűleg a hasznalt implementáció közvetlenül a writer-be nyomta bele a cookie headert. Vegül is senki nem irja elő, hogy a setCookie-t kell használni.

Na itt adtam fel. Talán még az lenne megoldas, hogy egy Wrapper osztállyal az egész Response outputot bufferelem, ha még nem volt session, és a végen parsolom a header-t. Na de ez már olyan nagy áldozat lenne, hogy inkább alábbadok az igenyeimből. (Vagy ilyenkor kene hozzaszolni a JSR-hez?)

Sun Java Studio Creator

Nem tudom pontosan mikor, de csak néhány napja, hogy a legfrissebb javításokkal a fenti program más tapasztalatai szerint 50-90%-ékkal gyorsabb lett. Ennek örömére újra megpróbáltam és tényleg javítottak rajta.

Bár én inkább annak örülten, hogy a most letöltött változat végre hajlandó Ubuntu alatt is elindulni. (Kb 3 hónapja még a projekt létrehozásakor széthallt az egész és hosszas guglizás és bugreportolás sem segített).

Egyébkén a fenti tapsztalatok (mármint hogy gyorsabb) nem az enyémek, hanem csak hallomás, és azt is mondták, hogy bugos-bugos, de már nagyon jól használható.

Hát nem tudom. A visual összerakóját én inkább fentartásokkal kezelném, de azt hiszem a JSF-be most már mindenképpen bele kéne mélyednem egy kicsit.