2006/12/04
Utóirat
Mikrokernel és kampók
Az OSGi különösen szimpatikus, van benne dependency kezelés, modularitás, futás közben-i deploy. Az egyetlen, ami hiányzik ezekből a rendszerekből, az a hook rendszer, amire szintén ácsingózok.
Aztán belegondoltam és rájöttem, hogy ez teljesen érthető. Ha van lehetőség egy szolgáltatást (interface-t) publikálni, és azt más szolgáltatásokból meghívni, akkor a publish/subscribe minta szerint már vidáman lehet remek hook rendszereket képezni bármelyi felé.
Valahogy így képzelem:
1. van egy HookSystem.java, ahová regisztrálni lehet egy interface konkrét implementációit (akár többet is)
//publish service
public void create(Class interfacez);
//subscribe to service
public void register(Class interfacez,Object o);
//execute the hook
public Object getHook(Class interfacez);
Például:
HookSystem system = new HookSystem();
//publish
system.create(hookertest.Hook.class);
//suscribe
system.register(hookertest.Hook.class,new HookImpl1());
system.register(hookertest.Hook.class,new HookImpl2());
//get the executor
Hook hook = (Hook) system.getHook(hookertest.Hook.class);
hook.print("asdx");
Terménszetesen a két HookImpl* implementálja a Hook-ot.
2. és van egy parancs, ami meghívja az összes implementációt, aki regisztrálvan van. A vicc kedvéért ezt a HookSystem.getHook-on keresztül csinálnám, ami egy proxyt ad vissza a Hook interface-re, de bármit meghívva rajta az összes implementáló osztály végighívja a paraméterekkel (a visszatérési értékek kezelésén még gondolkozom, egyelőre legyen mindenki void, és a paraméterekbe irkálljon. Továbbá az is gyanús, hogy szép generic-kekkel még meg lehetne bolondítani az egészet.)
Hát így. Hook rendszerem van. Már csak valamelyik mikrokernel cuccost kéne átlátni.
2006/11/26
Régi idők
Az egész utóbbi héten Struts-oltam. A régi Strus-cal. Mentségemre legyen szólva, hogy kényszerítettek, annak ellenére, hogy az önéletrajzomban felvételnél feltünően a Spring szerepelt a Struts helyett...
De nem is erről akartam beszélni, hanem hogy egy jó JSF-es alap tudással a Struts mennyire nem okozott meglepetést. Azt szokták mondani, hogy a JSF-et a Struts-on keresztül lehet eladni, mert az egyik specifikálója az a Craig McClanahan, aki a Strutsért is felelős.
Én azonban pont fordítva közelítettem, és ez se volt kevésbé izgalmas. Ismertem a JSF-et, és ez alapján a Strutsba nagyon könnyen el lehetett tájékozódni. Meg tippeltem, hogy minek hol kell lennie, és ott volt. Hiába, nagyon ugyanaz a kettő gondolkodása. Van bennük nagyon sok érdekes dolog, de azért az is érezhető, hogy mennyire távol áll az egész felfogás a Springtől. (Ellentétben a Spring-ből én személy szerint azt értem, hogy jó, hogy van egy elképzelésük az ideális felépítésről , de szinte mindent konkurencuát kipróbáltak, és mindennel össze passzintható.)
2006/11/20
RSS reader & writer
2006/11/13
EBJ3 speckó anomália
Hanem valaki igazán megmondhatná, hogy hogyan kell ezt a két mondatot egymás mellett értemezni:
"Note that a container can also invoke the PreDestroy method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired. " (4.4 page 76 utsó bekezdés közepe-vége)
"The following scenarios result in the PreDestroy lifecycle callback interceptor method(s) not being called for an instance:
[...]
A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB container implementation-specific way." (4.4.3 page 81 alja - 82 teteje)
Most hogy nagyon töröm a fejem, esetleg arra gondolna, hogy method ready állapotból PreDestroy-jal timeout-tol, passive-ból meg anélkül? De azt azért ennél egyértelműbben is meg lehetne fogalmazni. Talán egy következő fejezetből kiderül. Ötlet?
2006/11/07
XSLT vs. Java
(És akor nem beszéltünk a tesztelésről.)
Most olvasomtam itt: Simple Xalan excension function, hogy ez másnak is hiányzik: Xalan-ból kis namespace trükközéssel meg lehet hívni bármilyen Java függvényt. Persze innentől kezdve Xalan specifikus lesz az XSLT-nk.
Úgyhogy akkor én már inkább maradok a dom4-jnél, ahol egy az egyben lekódolták az XSLT algoritmusát Javaban, és egy egyszerű apin keresztül lehet XPath alapú rule-okat mondani. Jelentem használom és működik.
2006/11/03
Glassfish + PHP + Drupal
A helyzet nem túl bonyolult még glassfish-ben sem, ahogyan ebben fórumban is írják. Le kell tölteni PHP/Java Bridge binárisát (war file). Kísérlet képpen deployolhatjuk is rögtön, és (nekem a JSF integráció kivételével) rögtön ment is minden demo szépen (session megosztás, php-ból java hívás, stb.).
Saját webalkalmazás sem volt bonyolultabb. Kísérletképpen, hogy egy echo "asd"; nél bonyolultabb alkalmazást vegyek a Drupal rendszert akartam látni működni.
1. Csináltam egy web alkalmazást
2. a JavaBridge.war-ból átmásoltam a web.xml-t (lényege, hogy a *.php-re a saját szervletét meppeli be).
3. a /WEB-INF/lib-ből a php-servlet.jar és a JavaBridge.jar-t hoztam át
4. feltelepítettem a php5-cgi csomagot (demo deployolásakor még nem volt fent! mivel a demo önmagában tartalmaz a WEB-INF/cgi-ben php binárist is)
5. bele a gyökérbe a php fájlokat
6. deploy, és minden szép
Persze még lehetne további dolgokkal kísérletezni. A szemem sarkából láttam, hogy elég komolyan lehet egymásba integrálni a kettőt (pl. az egyik demo java-s excell api-t használt php-ből.) Meg ki kéne valahogy mérni a sebességet is.
De kezdetnek elég lesz ez: könnyű sikerélmény.
2006/10/31
Keep working
jBluez
A BlueZ a linux bluetooth stack-je, a JBluez egy JNI-s adapter hozzá. A SourceForge múzeumból egy 2002-es release tölthető le hozzá, ami megdöbbentő módon teljesen jól működik. Van hozzá 3 rövid példaprogram, megy egy rövid txt, hogy hogyan leheljünk bele életet, és egy mégrövidebb Troublehooting Guide, hogy hol fog elszálni. És tényleg elszállt ott, és tényleg úgy lehetett kijavítani, és utána tényleg ment. El voltam ájulva.A szomorú az benne, hogy nem JSR-82 kompatibilist, de olyat még nem sikerült találnom Linux alá.
(Közbe frissíŧettem az ubuntu-mat, és ebben már libbluetooth2-van, és a bináris nem azzal ment. De egy szimbolikus linket megkockáztattam (új api a régi néven is), és megette.
OpenSSO
Gyűrés alatt. Vicces, mert mindenhol azt írják, hogy az OpenSSO based on Sun Java Access Manager, de én sose tudom, hogy hogyan van a reláció. Pl. az OpenSSO-ban csak maga a web-app van, meg most már az adapterek, de a plusz konzolos alkalmazásokat még nem találtam meg. A dokumentációja is érdekes: felrakták a Use Case leírásokat, meg az architektúra leírásokat, amit elég izgalmas olvasni, (milyen egy Sun-os ilyen), de a használatról nem sok. Csak admin és config guide-ok, semmi development útmutatás.Van viszont elég sok cucc a docs.sun.com-on az Access Manager-hez, de az meg ugye nem pont ez. Amire hivatkozik sokszor hiányzik, és lehet keresni, hogy azok a utility-k itt hol vannak.
Tutorialt egyelőre nem találok, csak WebService titkolódzosat a NetBeans tutorialok között, de én egyelőre csak sima SSO-t szeretnék egy web appban. Illetve van egy , de még 8.1-es glassfish-hez, abból talán még lehet valamit.
A lényegből eddig ezt látom: egy deployolt webalkalmazás maga az Access Manager. Lehet más szerverekre Agent-eket deployolni, amik szintén webappok. Mivel ezek már a célalkalmazással egy domain-en futnak, ezért ha ezek kommunikálnak az Access Manager-rel, és után egy cookie-ba nyomják az eredményt, az elvileg a célalkalmazásból is hozzáférhető, és kezelhető.
Agent glassfishez csak 8.1-hezvan, de majdnem felment a 9-re, sőt valakinek állítólag ment is. A 8.1-eshez viszont demo is van, annak kéne mennie.
2006/10/25
J2EE security
Azt, hogy mit tud, és mit nem, elég jól összefoglalja ez a cikk, szépen körbejárja az 1.4-ben lévő dolgokat (a részletességre jellemző, hogy olyan fejezetek is vannak benne, hogy What is a container? De ennek ellenére tényleg korrket.)
A cikk a container security megoldásira ezeket az előnyökket mondja:
- beépített, tehát nem kell nekünk szarozni a session-ba rakosgatásával a User objektumoknak
- kőbe van vésve az apija (csinálhatunk pl. taglibrary-t a használatához, ami mindenhol menni fog)
- a több webapp között (egy szerveren) hordozni lehet a a belépési információt
- Átmegy a webtier és a business tier között
Nekem ebből az utolsó a legmeghatározóbb. Az azért tényleg kényelmes, hogy weben authentikálok, és EJB-k között is meg lesz a user info. Viszont cserébe a container semmit sem ad. Nem lehet jól bővíteni, az apija minimális, auditálás 0, stb.
Van ugyan a JAAS, de ahogy a cikk is írja:
Pl. a Sun Java Application Server-ben egy com.sun-os osztályt kell leszármaztatni saját realm írásakor, ami ugyan leszármazottja a JAAS osztályoknak, de egy másik appserveren hajunkra kenhetjük az egészet.
Az meg már csak hab a tortán, hogy a JAVAEE 5 speckóban ilyen kedves bekezdések vannak:
dynamically, allowing users to register themselves as new customers. This scenario
was widely discussed in the servlet expert group (JSR-53) but we were unable to
achieve consensus on the appropriate solution. We had to abandon this work for
J2EE 1.3, and were not able to address it for J2EE 1.4, but hope to pursue it further
in a future release.
(kiemelés tőlem)
Nem marad más hátra, mint mindenféle külső szoftvert használni. Ezek közül is 2 megoldást találtam:
- Gyártófüggetlent, ami csak a servlet apira épül, jól hordozható, és általában elég pehelysúllyú.
- Robosztus megoldásokat, amiktől gyártófüggő lesz a kódunk, viszont SAML-tól kezdve mindent tud.
Azt utóbbira (amennyire látom) példa a Sun (Java System) Access Manager termék, ezt még nem sikerült mozgás közben látni, az előbbire viszont egy elég jó (bár nem túl friss lista) olvasható itt.
Amiket ebből megnéztem
jGuard: Ez nézett ki a legjobban, valamennyi doksija is úgy tűnt, hogy van, van nem túl régi release, és a tervezése is elfogadhatónak tűnt távolról nézve. Gyakorlatban viszont se Tomcat-tel se Glassfish-sel nem sikerült működésre bírni a doksija alapján. 3-4 óra szívás után frissen telepített Tomcat-tel (NetBeans embedded-del nem) a példa alkalmazást sikerült feléleszteni.
Amúgy Pure JAAS modulokat eszik, valószínű, ha egy kicsit szájbarágósabb, precízebb leírása lenne, még tetszene is.
Kasai: Ezt még több helyen linkelték: 2005-ös release. Azt mondja, hogy az ő saját API-ja sokkal jobb mint a JAAS. Hát lehet.
Seraph: Atlassian, tehát már ajánló levél, plusz tisztességesen legenerált lap/doksi (maven). A SSO menüpont alatt viszont azt ajánlják , hogy úgy használjuk SSO-nak, hogy egy szerveren autentikálunk, ott egy cookie-t ragasztunk a kliensre a user névvel. És ha a domain alatt egy másik alkalmazáshoz téved a felhasználó, automatikusan beléptetjük a cookie-ben tárolt felhasználó nevére. Ezt vagy nagyon nem értem, vagy nagyon gyanús. A cookie-k mintha kliens oldalon lennének, és azt a user nevet írom bele, amelyiket akarom.
Gabriel: Azt mondja azt adja mint az EJB (ami nem túl sok) csak EJB nélkül. Mellesleg halott
Mindig óvva intenek, hogy feltaláljam azt, ami már úgyis meg van, de egyelőre úgy tűnik, hogy ha normális security szolgáltatásra lesz szükségem nekem kell majd implementálni.
2006/10/19
DOM4j vs JDOM
Mindkettő tud írni és olvasni SAX-ból és DOM-ból. a JDOM azzal reklámozza magát, hogy sokkal egyszerűbb, mert milyen jó dolog olyanokat írni, hogy
Element e = new Element();A dom4j ezzel szemben viszont sokkal jobb :-)
Jó elismerem, kell hozzá factory, hogy létrehozzunk egy új element-et (illetve ez sem biztos, mert csak a gyökér elemhez kell, utána lehet az element.addElement("gyerekteg") -gel is létrehozni új gyerek elemet, ami visszaadja az új elementet.
Viszont cserébe minden csak interface. Alatta a beállításoknak megfelelően különböző implementácíójú osztályok lehetnek. Van pl. olyan, ami egy kicsit több memóriát eszik, de sokkal gyorsabban keres attributumokra, van olyan, ami olyan dom4j komponens fát csinál, ami simán castolható DOM fává (nem kell egy új DOM fát építeni a konvertálásnál), és ez azért elég szép dolog.
Van benne még mindenféle adapter Swing-es elemekhet (pl. TableModel), tud XSLT-jellegű transzformációt (Rule-oknak hívja magát), amit két bejegyzéssel ezelőtt szerettem volna. A gyerekeket meg tudja mondani List-ben, Iterátorban, vagy egyenként (for ciklus). Szépen kezeli az XPath-t, keveset fogyaszt, és a dokumentációja is egy újnyival több mind a JDOM-nak.
2006/10/15
Maven2
- Létrehozni
- Librarykat hozzáadni
- Megírni a kódot
- Buildelni
- Tesztelni
- Futtatni
- Csomagolni
- Publikálni
Akkor nézzük mit ad nekem ehhez Maven, es mit a hagyományos IDE alapú fejlesztés (nálam NetBeans)
Létrehozás: Mivel csak standalone Java programot csináltam nem volt szükseg bonyolult archetypokra. Netbeans kreálta alap pont olyan jó volt mint a Maven-es.
Libraryk: Az nagyon okos, hogy a Maven egy helyen tárolja a függősegeket (azaz csak egy helyen kell meglennie pl. a log4j.jar-nak), de ugyanezt az IDE-k is tudjak. Igaz, itt fontos, hogy az összes hasznalt gepen ugyanolyan nevű shortcutokra legyen beallitva a jar file. Ha több gépen is fejlesztjük az egy projektet nagyon hasznos lehet, hogy a Maven library hivatkozás globalis, tehat ha beirjuk mi a függőség, bárhol is vagyunk letölti neküknk uazt a jart.
Megírni a kódot:Sajnos ezt is kell, és hiába csinál egy csomó mindent meg helyettem a Maven, ha a programozást segítő kiegészít funkciók közben meghallnak az IDE-ben, akkor nem fog érdekelni a dolog.
Buildelni/tesztelni: Ez mindkettőben ugyanaz az élmény. Bár Buildelni Netbeansben csak a saját ant build szkriptje alapjan sokkal gyorsabb, mint meven ide-n keresztul.
Futtatni: Ezt Mavenben vagy úgy eldugták, hogy nem találtam, vagy nincs. Ideből röhögve.
Csomagolni: Netbeans alapból jar csomagot állít elő, a dist könyvtárba. Maven plugin némi szöszölés után sokkal jobban testreszaható. Bár azt hiszem ant alapon a NetBeans-et is meg lehetne tanítani okosabb dolgokra.
Publikálás: Ebben egyértelműen a Maven a nyerő, site-ot csinál, reportokat generál.
Szóval itt tartok. Próbáltam a mevenide-t NetBeans-hez, nagyon szép, csak pont a finisben hasal el. Pl. ha Maven projektet nyitok nem használhatom a persistence-s varázslókat. EJB3-mal meg se mertem próbálni. Ha csak command line-ból használok Maven-t, és fejlesztéshez NetBeans-t akkor is iszonyú szívás a dolog.
A Maven a library kezelésben nagyon erős, meg a site deployban, de emellett hiába van róla ingyenes könyv, meg a honlapon elég sok guide nagyon nehéz eligazodni a doksikban, és advanced dolgok már nincsenek nagyon leírva. A library kezelést lehet mással is helyettesíteni (pl. Ivy), de a report generálás azért hiányozni fog.
2006/10/12
XSLT logika javaban
Jo, csinaljuk meg Javaban. Kell egy olyan dolog, ami vegigmegy az XML-fan, minden node-nal megkeresi a legjobban illeszkedo szabalyt (az illeszkedest tetszoleges bonyoult XPath-szal definialom), es lefuttatja.
Az hamar eldolt, hogy SAX nem lesz jo, hisz ott az Event fuggvenyek csak string-eket kapnak, a dom poziciorol semmit sem tudnak, es a szabalybol sem tudok kinezni a dom mas agai fele.
Akkor legyen DOM (ugye mindig mas XML kell, schema nem is bitos, hogy van ezert a JAXB, ami szinten DOM szagu, nem jon szamitasba.). A problme az, hogy meg nincsenek meg azok a fuggvenyek, amik a DOM fa kurrens poziciojanak XPath-at ossze tudna vetni egy adott szabaly/listener elore, esetleg teljesen mas alakban megadott szintakszisaval.
Viszont, egyreszt a Xalanban van XSLT motor, ugy hogy o megcsinalja valahogy, illetve van meg az xsltc, ami java byte code-ot fordit xslt-bol (mar jol hangzik). Szoval ilyen iranyban guglizunk tovabb.
2006/10/06
Netbeans 5.5 RC1
Igazából csak arról akartam írni, hogy miután sikerült JSF CRUD-ot összelőcsölnöm mindenféle doksi alapján, megtaláltam a Netbeans-ben, hogy DB alapján néhány gombnyomással legenerál ő mindent.
Szóval akkor már: kijött a napokban az RC1. Persze a changelog-ot sehol se találom, mert az már a véglegeshez van, de néhány új code generáló mellett (pl. JMS hívás) találtam pl. Kodo-t és Hibernate-t is a persistence unitok között.
2006/10/01
Java persistence api
A mondás az, hogy azért került be csaj az EJB3 JSR alá, hogy gyorsabban át lehessen nyomni a processen. Ezzel szembe akár standalone alkalmazásokba is lehet használni.
A lényege, hogy Pojo entitásokat használ, és egy absztrakt apit definiál, amivel perzisztálni lehet ezeket. Descriptor helyett pedig annotationok vannak a Pojoban.
Szép, egyszerű: ide is rakok egy példát az íze kedvéért:
Az entitás
package jpasample;
import java.io.Serializable;
@javax.persistence.Entity
public class SampleEntity implements Serializable {
@javax.persistence.Id
private Long id;
public SampleEntity() {
}
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
public int hashCode() {
int hash = 0;
hash += (this.id != null ? this.id.hashCode() : 0);
return hash;
}
public boolean equals(Object object) {
if (!(object instanceof SampleEntity)) {
return false;
}
SampleEntity other = (SampleEntity)object;
if (this.id != other.id && (this.id == null ||
!this.id.equals(other.id))) return false;
return true;
}
public String toString() {
return "jpasample.SampleEntity[id=" + id + "]";
}
}
A meghívó program már egy kicsit bonyolultabb, de csak a tranzakció és kivétel kezelés szórta meg nagyon.
package jpasample;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
public class Main {
//private static EntityManagerFactory emf =
Persistence.createEntityManagerFactory("TopLinkPU");
private static EntityManagerFactory emf =
Persistence.createEntityManagerFactory("HibernatePU");
public static void main(String[] args) {
new Main().run();
}
public void run(){
EntityManager em = emf.createEntityManager();
SampleEntity entity = em.find(SampleEntity.class,1l);
if (entity==null){
System.out.println("nincs ilyen");
entity = new SampleEntity();
entity.setId(1l);
em.getTransaction().begin();
try {
em.persist(entity);
em.getTransaction().commit();
} catch (Exception e) {
e.printStackTrace();
em.getTransaction().rollback();
}
} else {
System.out.println("van ilyen");
em.getTransaction().begin();
try {
em.remove(entity);
em.getTransaction().commit();
} catch (Exception e) {
e.printStackTrace();
em.getTransaction().rollback();
}
}
em.close();
}
}
És persze kell hozzá még egy descriptor is, hogy melyik Persistence Api implementációt használjuk:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="TopLinkPU" transaction-type="RESOURCE_LOCAL">
<provider>
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider
</provider>
<class>jpasample.SampleEntity</class>
<properties>
<!--<property name="toplink.jdbc.url" value="jdbc:derby:asd;create=true"/>-->
<property name="toplink.jdbc.url"
value="jdbc:derby:asd"/>
<property name="toplink.jdbc.user"
value=""/>
<property name="toplink.jdbc.driver"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<property name="toplink.jdbc.password"
value=""/>
<!--<property name="toplink.ddl-generation"
value="create-tables"/>-->
<property name="toplink.jdbc.url"
value="jdbc:derby:asd;create=true"/>
</properties>
</persistence-unit>
<persistence-unit name="HibernatePU"
transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<class>jpasample.SampleEntity</class>
<properties>
<property name="hibernate.connection.url"
value="jdbc:derby:asd;create=true"/>
<property name="hibernate.connection.driver_class"
value="org.apache.derby.jdbc.EmbeddedDriver"/>
<property name="hibernate.connection.password"
value=""/>
<property name="hibernate.connection.username"
value=""/>
</properties>
</persistence-unit>
</persistence>
A NetBeans (5.5 beta 2), amivel ezekenek a kódoknak a nagyrészét generáltam az Oracle TopLink Essential-ját használja. De látható, hogy Hibernate Entity Manager-rel is ment a dolog szépen, csak az EntityManagerFactory konstruktorában kell más persistence-szre hivatkozni. És ez azért nagy királyság: kész a program, de még cserélgethetem a persistence megoldást, hogy megmérjem melyik jobb nekem.
Alapvetően egyébként a JDO is hasonló lehet (múltkor belelapoztam egy könyvbe), elvileg meg is van ígérve, hogy a két speckót egyesítik. De a JPA mellett szól az is, hogy az EJB3 pihepuha Entity Bean-jei is ezt használják.
2006/09/26
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?
2006/09/21
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.
2006/09/20
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.2006/09/06
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?)
2006/09/05
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.
2006/08/28
JavaBeans és O/R mapping
Egy kevéssé típusos nyelvben olyat is láttunk már hogy lekérdezés előtt az sql query-t keresztül eregették néhány kiterjesztő modulon valamilyen hook rendszer segítségével, és mindegyik modul átformálta úgy a lekérdezést, ahogy ő szerette volna (pl. hozzácsapott valamit). A választ meg majd szintén keresztül eregették a hook systemen, és minden modul szemezgetett
belőle, és felhasználta az eredményben a kapott plusz mezőket.
Ez eddig nem nagy szám. Javaban is meg lehet ezt csinálni. Mondjuk én szívem szerint kipróbálnám, hogy nem a query String referenciáját küldeném át (ez a String viselkedése miatt nem is lenne annyira jó) hanem csinálnék egy Query osztályt, amihez tagfüggvényekkel tudnék hozzáadni plusz WHERE, ORDER BY stb. feltételeket.
Aztán megkapnám az eredményt. Ez is száll ágról ágra, és minden modul ki tudná venni pl. res.getString("plusz mező")-vel plusz oszlopokat a ResultSet-ből, amiket az sql módosításával ő biztosított magának.
A probléma ott van, hogy múltkor elkezdtem O/R mapping-gel kísérletezni, és az első egyszerű példák valóban nagyon kellemesen kézbe símultak. Csakhogy O/R mapping-gel az adatbázis válasz struktúráját beledrótozzuk a bean osztály szerkezetébe, amit nem fogunk tudni sehogy sem kiterjeszteni (a leszármaztatás már rögtön a több modulnál elvérzik, de az interface implementálás sem járható út).
Őszintén szólva nem ismerem ilyen mélyen az O/R mapping megoldásokat, hogy erre milyen megoldásokat ismer. Két dolog kéne
- egyrészt, hogy a lekérdezéskor ki lehessen terjeszteni az (?)SQL lekérést plusz WHERE, JOIN stb. feltételekkel
- és az így kapott plusz mezőket valahol visszaadja
tudjuk, hogy a lekérdezésnek az egyes oszlopaiból melyiket melyik JavaBean-be dobjuk szét.
Nem tudom sikerült-e jól artikulálnom a problémát, de szerintem elég szerény kívánalom. Talán tudja is valamelyik O/R mapping cucc, csak sokkal mélyebben el kéne olvasni a doksikat.