Originariamente inviato da fuoricorso
Ti ringrazio per le tue risposte, sei hai un po' di tempo volevo sapere perchè hai incluso quel jar di commons-logging-1.1.3.jar per le dipendenze, deve essere sempre incluse nei progetti.
commons-logging è una dipendenza "storica" di Spring.
Puoi leggere sulla documentazione ufficiale (3.2):
http://static.springsource.org/sprin...erview-logging

e sul SpringSource Blog:
http://blog.springsource.org/2009/12...ies-in-spring/

Loro stessi (quelli di SpringSource) ammettono che se potessero oggi rifare Spring Framework da zero, utilizzerebbero non la commons-logging ma la SLF4J, che è un altro "facade" (facciata) per una libreria di logging.

La cosa buona di commons-logging è che se non trova in classpath una libreria di logging (come Log4J), si limita ad usare il logging del JDK (java.util.logging) che per default, senza configurazioni particolari, stampa su console (standard-output).
Per questo motivo non ti ho detto altro sul logging nel mio esempio: di base ottieni, e a gratis senza configurazione, il log su standard-output.

A volte insieme a Spring si usano altre librerie (es. Apache Tiles) che richiedono SLF4J. In tal caso invece di avere due facade di logging e altre complicazioni, si tende ad avere una gestione comune per il logging. Si può usare la jcl-over-slf4j, che implementa la stessa API di commons-logging ma in realtà "butta" il log su SLF4J, il quale, con un jar apposito di implementazione, è in grado di loggare ad esempio su Log4J.
Sono scenari un po' più avanzati, questi. Se ti ho detto cose o nomi che non comprendi, non c'è problema. Se stai iniziando con Spring, includi la commons-logging e hai il tuo bel log su console, di serie.

Originariamente inviato da fuoricorso
In rete ho trovato alcuni esempi di esercizi a volte mi danno errori perchè il codice è deprecato e devo cercare di modificarli facendo uso di altre classi o metodi.
Sì, anche Spring Framework, evolvendo, rende deprecate alcune classi man mano che le versioni si susseguono. Nel mio esempio, se avessi usato Spring Framework 3.0 o inferiore, avrei potuto usare XmlBeanFactory che era un pochino più diretta e semplice da usare. Ma dalla 3.1 è deprecata.

Originariamente inviato da fuoricorso
Ho provato il tuo esempi e funziona ovviamente ;-) ma certe classi non li avevo ancora viste, sai dirmi dove posso trovare un buon tutorial?
C'è il Reference Manual e il javadoc ufficiali di Spring Framework sul sito http://www.springsource.org/spring-framework

Originariamente inviato da fuoricorso
Ho provato a fare un esercizi proposto dal tutorial del sito html ma per alcune classi mi davano problemi perchè era codice deprecato ho cercato di usare altre classi e interfacce per il container ma comunque mi da errore dicendomi che non trova il file bean.xml, secondo te qual'è il problema?
Innanzitutto tieni presente che una cosa è una "bean factory" (come nel mio esempio) e un'altra cosa è un "application context".
Entrambi offrono alla base il container che contiene i bean e permette la dependency injection. Ma un application context offre molto di più (anche qui: la reference ufficiale lo spiega in dettaglio).

Originariamente inviato da fuoricorso
codice:
   ApplicationContext app = new ClassPathXmlApplicationContext("bean.xml");
bean.xml viene cercato usando il classpath (lo si vede dal nome della classe) e il file, non essendo xyz/bean.xml, viene cercato "alla radice" in classpath, ovvero non in un package. Dipende quindi dove hai messo bean.xml. Se ReportClient è in un package e bean.xml l'hai messo in quel package ... è ovviamente sbagliato.

Se vuoi che bean.xml sia relativo al package di ReportClient (concettualmente proprio come ho fatto nel mio esempio), usa l'altro costruttore:
ClassPathXmlApplicationContext(String path, Class clazz)