Nel progetto che sto seguendo adesso in ambito Azure Cloud con il team abbiamo adottatato come soluzione di persistenza Azure Cosmos DB for MongoDB. Per velocizzare gli sviluppi abbiamo integrato Spring, in particolare spring-boot-starter-data-mongodb, per poter utilizzare agevolmente i MongoRepositories e non doverci preoccupare degli strati più bassi dell’applicativo. Tutto figo, scrittura che va senza problemi, fino a quando non decidiamo di fare anche operazioni di lettura e ci scontriamo con questa eccezione oscura:

Caused by: com.mongodb.MongoTimeoutException: Timed out after 30000 ms while waiting for a server that matches ReadPreferenceServerSelector { readPreference= ReadPreference {name=secondary, hedgeOptions=null}}. Client view of cluster state is {type=REPLICA_SET, servers=[{address=*, type=REPLICA_SET_PRIMARY, TagSet{[Tag{name='region', value=''}]}, roundTripTime=199.7 ms, state=CONNECTED}

Tutto quello che si trova in rete non ci permette di risolvere perchè non va, fino a quando non rivedo la configurazione adottata con Spring

E qui finalmente si svela l’arcano. Essendo un cosmosdb configurato per il dev per limitare i costi non abbiamo attivato la read replica, mentre da nella configurazione avevamo specificato di leggere il secondario che non era stato attivato. L’eccezione non proprio parlante non ci ha permesso di individuare subito, ma per risolvere agevolmente è stato sufficiente cambiare la configurazione in questo modo

Personalmente reputo jasper reports un prodotto ottimo, permette di elaborare report di elevata complessità permettendo di concentrarsi sugli aspetti più importanti come la presentazione senza aver bisogno di una conoscenza approfondita di librerie per gestire i vari formati pfg, xls, csv, …

Lo stack tecnologico si evolve con il tempo e capita che soluzioni adottate precedentemente non siano più percorribili. E’ il caso di jasper report e spring boot. Spring boot, altro prodotto validissimo, ci permette di generare dei jar eseguibili che tramite l’uso dei tomcat embedded ci permette di tirare dei servizi web senza particolari problemi. Non hai più la necessità di gestire una istanza tomcat, e di generare il war che va installata su di essa, ma generi un jar che eseguito espone il servizio richiesto. Se all’interno del jar prevediamo la presenza dei template jasper per l’elaborazione del report occorre non più fornire il path ma fornire questo template sotto forma di inputstream. Su questo argomento avevo già scritto un articolo che trovate qui.

In questi giorni però mi è capitato di dover gestire un report che a suo volta conteneva un subreport passato sotto forma di path ed ecco che si è ripresentata di nuovo l’eccezione FILENOTFOUNDEXCEPTION, perchè giustamente anche il subreport va passato come inpustream per risolvere il problema.

Ricapitolando:

In JasperReport definisco un parametro di tipo inputstream

Lo utilizzo come espressione del subreport

E nella classe java dove invoco il metodo per la generazione del report lo passo come parametro

params.put("SUBREPORT_INPUTSTREAM", report.getInputStream());

Buon lavoro