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.