Siamo tutti un po’ innamorati della Dependancy Injection (DI), come quella di CDI per esempio: ci piace per l’estrema eleganza del codice, per il disaccoppiamento tra classi, per mille altre ragioni del mondo, e un po’ anche per pigrizia! Purtroppo però, esistono situazioni in cui l’idillio si infrange e la DI non viene risolta dal nostro Inversion of Control (IoC) container preferito: ci sono infatti alcuni artefatti come i Converter e i Validator di JSF che non sono gestiti da questi contesti, non meno lo è CDI. Urge un lookup programmatico! Vediamo come fare.

Tra le novità della piattaforma Java EE 6, sicuramente spicca CDI. Spring e Seam hanno fatto scuola e il meglio entra nella specifica Java Enperprise. Uno dei primi concetti con cui dobbiamo fare i conti è il lifecycle dei bean CDI, governato dagli scopes. Già da subito si nota che molti di questi scope si sovrappongono a quelli della specifica JSF 2, e il fatto che i bean CDI siano referenziabili anche da pagine web tramite Expression Language (EL), fa pensare che CDI stia invadendo il campo di JSF. Cerchiamo di capire su cosa.

Per chi è cresciuto a pane e GoF non sarà certo la prima volta che sente parlare del Pattern Decorator. In due parole, questo pattern permette di aggiungere in modo modulare funzionalità, a compile-time, ai metodi di una classe esistente, mantenendone l’interfaccia intatta. L’aggiunta o la rimozione di queste funzionalità risulta quindi totalmente trasparente all’utilizzatore. Nel contesto attuale dello sviluppo Java, sempre più governato da “container” che risolvono automaticamente le dipendenze, implementare questo pattern poteva non essere banale fino a ieri. La nuova specifica Context and Dependancy Injection (CDI) introdotta in Java EE 6 invece supporta nativamente i decoratori: vediamo come.