One RSS to rule them all

Csináltam egy yahoo pipe-ot, ami összeönti a magyar java blogok tartalmát egybe. Ez van most kint, oldalt, csak van belőle egy változat, amiben nincs benne a saját blogom RSS feedje. Nyilván azt minek ide kitenni :-)

• pipe (ha esetleg clone-oznád)
• rss - ha olvasnád vagy kitennéd valahova
• twitter acc - ha az rss nem elég trendi

Ha valaki blogját kihagytam, szóljatok! Sajnos nem sok az aktívítás, sok blog vált inaktívvá az utóbbi 2-3 évben :-(

TestNG apocalEclipse

Szóval az eclipse support gyógyítása: eclipse restart. Érdekes. A teszt paraméterezés is megyeget, de ezt még nem igazán találtam ki hogy hogyan kellene használni. Azt szeretném, ha a Continuous Integration szerveremen (continuum konkrétan) be lehetne paraméterezni hogy milyen adatbázis szerverek vannak installálva például és azokon minden végrehajtani a DAO implementációk tesztjeit, és persze minden implementáción. Ha már egyszer elvetemült idealista vagyok akkor abban már nyugodtan lehetek szélsőséges fajta :)

Amúgy ma miközben az itthoni miniclusteremet pofozgattam elszállt a másfél éves maxtor vincsim, amin egyébként a home partíciót is tartom, de kimenekítettem. Vegyetek ti is sok maxtor vinyót, nagyon jó hangja van amikor azt mondja hogy "nyekkk"!

N-edik visszapattanás a TestNG-ről

Ma ismét megpróbáltam átportolni egy projectemet TestNG-re, mert nagyon megtetszett hogy jobbára már működik az eclipse TestNG pluginja a 3.2-es eclipsemmel. Hoz pár olyan dolgot ami frankó lenne végre bevetni, test grouping, paraméterezés, ilyesmi.
Aztán rájöttem hogy az eclipse pluginja is csak jobbára működik, a maven-nel a 5.1-es verzió pedig egyáltalán nem. Kb ugyanez áll a Junit 4.1 verziójára, annyi kivétellel hogy az eclipse alapból tartalmaz már egy "junit 4" futtatókörnyezetet, ami konkrétan junit 4.1-gyel megy. Tökre nem mindegy hogy 4 vagy 4.1, de stablinak tünik. Már csak maven support nincs hozzá.
A surefire SVN-beli verzióján is látszik hogy 5.1-es testNG-vel tesztelik, úgyhogy lehet figyelni a surefire 2.3-as verzióját, vagy átnyergelni a SNAPSHOT-ra és lőni mozgó célpontra.

A törpök élete se csak játék és mese. Mint azt közismert :)

Spring context xml-es okoskodás

Visszatérve kicsit a hiperkorrekt maven rad-os gondolathoz (de nem csak azzal kapcsolatban), hogy ugye előre definiált datasource-ok és ilyesmi, csak most kicsit több aspektus. Konkrétan a yikulju kódjában próbálok valami végleges és nagyon pöpec rendet teremteni a unit tesztek közt, és itt jutott eszembe az hogy ha már lehetőség van a tesztek paraméterezésére, akkor megoldhatjuk azt hogy a például egy DAO teszt lefusson a fejlesztő környezetétől függően Derby-n vagy PostgreSQL-en. Mióta O/R mappinget használ az ember felületesen fölöslegesnek tünhet mindez, de azért van pár kivétel amire jó elég korán rádöbbenni, ha nem kerül túl nagy erőfeszítésbe.

Na, megint elkóboroltam a kiszemelt témától. Szóval a spring context XML-t hogyan robbantsuk fel darabokra úgy, hogy az elég rugalmas legyen és ne kelljen beleírkálni egynál több file-ba a végfelhasználóknak. Ezzel jól célozza az ember a the long tail-ben található felhasználóbázist, de még nem zárja ki a nagyhalakat sem :)

Na és valami ilyesmit találtam ki erre:

• Az adatbázis connection pool kerül külün context xml-be, ilyen elnevezési tradícióval mint pool-...xml. Ennek konkrétan két implementációja lehetséges, az ultralusta végfelhasználók és minimalista futáskörnyezetek számra beágyazott commons-dbcp és a szabványos JNDI lookupos akármi. Mindkettő implementáció persze ugyolyan nevű beant definiál, pl "dataSource"
  
• Adatbázis függő adatok számára külőn XML-ek. Ez olyanokat tartalmaz mint a JDBC driver osztály neve (amire java 1.6-ban már nincs sokáig szükség, de most még kell ha senki más nem tudja), hibernate dialect, esetleg a compass dialect.
• Külső konfigurációs adatokat a kontextusba ágyazó BeanFactoryPostProcessor, ez idáig az egyetlen Spring-függő dolog benne, de ilyet talán máshol is lehet implementálni. A unit tesztek egyszerűen csak importálnak egy másik ilyen preprocesszort definiáló XML-t ami például a System.properties alapján helyetesít be konfigurációs adatokat és mehet is a műsor. Nem kellett copy-pastelni a konfigot alkalmazás és tesztek közt.
  Például amikor webappot hegesztesz, a webapp egyszerűen csak a web.xml-ben definiálja context változóként a kellő konfig adatokat és megmondja hogy a teljes alkalmazás melyik XML-ekben található bean-ekből áll össze. Emberi módon felsorolva, JNDI, postgresql, webapp, opcionális bean-ek.
  

És itt most az a kérdés vetődik fel hogy ez vajon tényleg elég egyszerű-e a fejlesztőknek és a felhasználóknak, valamint elegendő plusszt nyújt-e ahhoz hogy ezzel érdemes legyen egy konkrét fejlesztés során babrálni. Kiderül.

Java 1.7 fejlesztőbosszantó

A java.net-en már a sokadik kérdés van szavazáson a jdk 1.7 (vagy marketingeseknek 7.0) újításairól. Az eddigi eredményből a Language-level XML support népszerűtlenségét emelném ki. A closures (vajon ezt magyarul hogy fogjuk mondani) viszont jól szerepel. A groovy biztosan bejött pár embernek :)
Izzik parázs vita a javaforumon is a dologról.

Compass vs Lucene

Vajon illik-e a másik project package struktúráját felvenni azért hogy hozzáférhessünk a package-protectred dolgokhoz benne? Aki kapott már olyan hogy "sealing violation", az valószinűleg azt mondja erre hogy nem igazán. Én már kaptam ilyet az arcomba, ott egy ravasz srác hekkelte meg az Oracle Advanced Queue package strukturát ahhoz hogy menjen Bea Weblogic alatt mint JMS. Jajj, azok a régi szép gyári hegesztőmunkás napok.

A jelenlegi eset az a Lucene és a Compass framework.
A compass framework sok hasznos dolgot adna, imádnám érte. A JDBCDirectory-n keresztül együtt tarthatjuk az indexet az adattal, ugyanaz a hely, ugyanaz a tranzakció. A Lucene helyett meg nincs más.
Szóval ezen is van mit kalapálni.
Mindenesetre a Yikulju-ban a lucene index directoryt is kipakolom külső context xmlekbe, legalább had legyen választása a felhasználónak még ha minden választás rossz is :(

Spring context és a java.util.Properties osztály érdekességei

Ez a probléma mindig előjön amikor spring contextekben java.util.Properties objektumot kell passzolni valamelyik objektumnak. A probléma az az, hogy a spring ilyan Properties objektumokat csinál:

Na és ez piszok mód statikus. Ebbe a properties-be senki nem szól bele. Többnyire ez nem baj, csak vegyük példának egy olyan esetet, hogy van egy hibernate-re épülő szoftverünk, amihez külön kontextusba kipakoltuk a hibernate különböző beállításait és az DataSource konfigot. Ebben az esetben azt szeretném, ha abban a külső XML-ben legyenek definiálva egyes tulajdonságok. Például a hibernate.dialect.
És akkor jön a gonosz Copy-Past Coding, mert ezt minden springes projectben ahol felmerül ennek az igénye ezt beletúrom.

public class PropertiesFactory implements FactoryBean {

 private Map properties;

 public Object getObject() throws Exception {
     Properties props = new Properties();
     props.putAll(properties);
     return props;
 }

 public Class getObjectType() {
     return Properties.class;
 }

 public boolean isSingleton() {
     return true;
 }

 public Map getProperties() {
     return properties;
 }

 public void setProperties(Map properties) {
     this.properties = properties;
 }

}

És innentől már lehet Map-ból csináni a Properties-t ezzel a factory bean-nel.
Na, erre szivesen megnéznék egyszer valami más megoldást :) Is there anybody out there?

Ötletelős percek - Maven RAD

Csináltam egy friss blogot, konkrétan ezt olvasod, írogatok majd ide mindenfélét technikai dolgokról. Java főleg, linux, clusterezés, open source projectek, villanydemokrácia, meg ami jön. Utálni fogtok érte :) Na, vágjunk egy "in medias res"-t a lovak közé!

Elmentem ma mérni, és mivel ez különösebben nem egy intellektuális tevékenység, azon gondolkodtam hogy összeállítani egy korrekt architektúrát web alkalmazásokhoz igencsak időigényes dolog, de vannak dolgok amivel meg lehet gyorsítani a fejlesztést.

Itt van például a grails. Beírod hogy ant create-project, ott is vagy, megvan a projected. Az acegit mondjuk kicsit kalapálni kellett, de legalább jobban képbekerültem groovy-ban meg acegiben. A friss grailsben viszont ott van az amin én is mennyit vacakoltam, openlaszlo integráció. Szóval közelebb hozza az álmot hogy a webapp-fejlesztés gyorsan elstartolható, meg ilyesmi. Feketemágia akad az ilyen *rails dolgokban bőven, nem csak a fejlesztőkörnyezetbe veszi be magát, hanem a futási környezetbe is, kiszedni meg nehezebb mint teljesen újraírni az egész cuccot.

Egy érdekes próba lenne maven alapra tenni egy RAD projectet, ami két részből állna.

1. Egy maven archetype, amivel gyorsan létre lehet hozni egy hiperkorrekt, bár üres projectet
2. Egy plug-in amivel gyorsan le lehetne generálni DAO interface-ket és implementációkat, valamint a view oldalból is létrehozna egy templatet.

És akkor definiálom hogy mi a hiperkorrektség nálam mostanság.

• külön projectekre elválasztva a modell, az alkalmazáslogika és a különböző felhasználói felületek (webes felület, web service, swing, portlet, ilyesmi), integrációs projectek
  
• deklaratív tranzakciókezelés alapból, mert tranzakciókezelés úgyis mindenhova kell, ha meg nem akkor úgyis könnyebb kivenni mint beletenni :)
  
• Azonosítás, dettó, bár ezen még azért érdemes lenne okoskodni
• Persze mindez korlátokkal, mert a tökéletes ember és szoftver még amerikai szuperhősfilmben sincs. Acegi, spring, alapból JPA-ra generált DAO-k. JPA mögé persze Hibernate, mert úgyis boldog boldogtala lecserélni meg elméletileg könnyű. Nem próbáltam még.
• Generált tesztek a DAO objektumokhoz, alapból például Derby-n, de persze opcionálisan bármi máson.
• Alapból beleintegrált riportok minden alprojecthez,
  

Az hogy a view dolgokat milyen framework-re generálja, azt nevezhetjük lényegi kérdésnek. Ezt jó lenne pluginelni.

Szóval elbonyolítani már sikerült, mindenesetre teszek egy próbafúrást a területen, hátha feltör az olaj és én leszek a Bobi Juing. Vagy a Dzsoki inkább, mer` ő gonosz.