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

@Override
protected void configureClientSettings(MongoClientSettings.Builder builder) {        
    builder
        .applyConnectionString(new ConnectionString(mongoUri))              
        .readPreference(ReadPreference.secondary());
}

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

@Override
protected void configureClientSettings(MongoClientSettings.Builder builder) {        
    builder
        .applyConnectionString(new ConnectionString(mongoUri))              
        .readPreference(ReadPreference.primary());
}

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

@NotNull
@NotEmpty
....

che coprono la stragrande maggioranza dei casi.

Quando il sistema riscontra l’errore restituisce il messaggio associato, es. not be not null

Qualora volessimo agevolmente localizzare il messaggio è sufficiente creare un file ValidationMessages_it_IT.properties sotto la directory resources del nostro progetto maven e il gioco è fatto

Es. del file

javax.validation.constraints.NotNull.message=Obbligatorio
javax.validation.constraints.NotEmpty.message=Obbligatorio