Sostanzialmente il messaggio indicava che uno dei vari plugin configurati nella build del processo non era gestito correttamente nel ciclio di vita gestito da STS. Nel mio caso si trattava del plugin jasperreports-plugin responsabile della compilazione dei file .jrxml in file.jasper e la condizione di errore veniva indicata sul tag execution

Per gestire l’errore è stato sufficiente sfruttare un’altra feature del maven, ovvero il dependency management e definire tramite un altro plugin (lifecycle-mapping) il comportamento di Eclipse. Il dependency managament è un tag disponibile all’interno del tag build.

Una volta aggiornato il pom, STS ha rimosso l’errore, compilato i file e generato i file jasper attesi.

E’ possibile configurare lo stesso plugin anche per ignorare il plugin incriminato all’interno della gestione di STS, in questo caso invece di usare l’action execute si usa l’action ignore

Per maggiori informazioni vi invito a leggere la documentazione ufficiale disponibile qui, mentre per l’ottimo plugin di compilazione di report la pagina ufficiale è questa.

test&cls

il comando ha l’effetto di svuotare la finestra da tutti i caratteri inseriti

Una volta che hai completato le tue specifiche ti consente di generare agevolamente il file json delle specifiche tramite il quale poter generare il client per invocare i tuoi servizi.

Per generare il file è sufficiente invocare l’url

http://<hostname>:<port>/v2/api-docs?format=openapi

La risposta sarà il file json da cui poter generare agevolmente il client.

select value from nls_database_parameters where parameter=’NLS_CHARACTERSET’;

che restituisce la stringa identificativa del character set, nel mio caso:

AL32UTF8

La prima soluzione è cambiare la porta che stiamo utilizzando agendo sul file di configurazione, la seconda soluzione è individuare il servizio che sta occupando la nostra parte e stopparlo.

In ambiente window per risolvere il problema occorre usare i comandi netstat per inviduare il processo e taskkill per eliminarlo

netstat -ao | find "10001"

con questo comando elenchiamo tutti i processi e filtriamo quello che occupa la porta 10001

TCP    0.0.0.0:10001          <nome>      LISTENING       9344

L’ultimo parametro indica il PID del processo incriminato e per eliminarlo usiamo taskskill

Taskkill /PID  9344 /F

La prima scelta è leaflet  che implementa la gestione di una mappa interattiva.  Per poterla usare è sufficiente realizzare una pagina html che chiami la pagina la pagina info.json dell’immagine desiderata, come illustrato sotto

<body>
<div id="map"></div>
<script>
var map = L.map('map', {
center: [0, 0],
crs: L.CRS.Simple,
zoom: 0, 
})
L.tileLayer.iiif('http://localhost:8182/iiif/2/0001_2.jpg/info.json').addTo(map);
</script>
</body>

se  avete operato bene chiamando la pagina html vedremo la nostra immagine con le funzioni di zoom attive.

Un altro client utilizzabile è  Openseadragon  , che aumenta il numero di funzioni a disposizione e presenta opzioni per gestire tutti i casi d’uso comuni. Se la banda non è un problema è possibile integrare l’immagine completa e demandare al client la gestione dello zoom

<body>
	<div id="openseadragon1"></div>
	<ul class="pgwSlideshow">
	</ul>
	<script src="openseadragon.min.js"></script>
<script type="text/javascript">
            OpenSeadragon({
                id:            "openseadragon1",
                prefixUrl:     "images/",
                immediateRender: true,
				        showNavigator: true,
                preserveViewport: true,    
                timeout: 60000,
                tileSources: {
                    type: 'image',
                    url:  'http://localhost:8182/iiif/2/0001_2.jpg/full/full/0/default.jpg'
                }
            });
        </script>
</body>

In questo modo scarichiamo il carico computazionale sul client e Cantaloupe non effettua elaborazioni, mentre se vogliamo sfruttare la potenza di Cantaloupe il codice da usare è il seguente

<body>
<div id="openseadragon1"></div>
	<ul class="pgwSlideshow">
	</ul>
	<script src="openseadragon.min.js"></script>
<script type="text/javascript">
            OpenSeadragon({
                id:            "openseadragon1",
                prefixUrl:     "images/",
                immediateRender: true,
				        showNavigator: true,
                preserveViewport: true,    
                timeout: 60000,
                tileSources: 'http://localhost:8182/iiif/2/0001_5.jpg/info.json'
            });
        </script>
</body>

java -Dcantaloupe.config=cantaloupe.properties -Xmx2g -jar Cantaloupe-3.3.5.war

La configurazione di default prevede che il server stia in ascolto sulla porta 8182, pertanto se avete fatto tutto correttamente accedendo al link http://localhost:8182/ comparirà la nostra home page, ovvero una bella fetta di cantalupo indicante la versione corrente.

A questo punto attiviamo il pannello di amministrazione. Per farlo accediamo al file di configurazione e attiviamo tramite la sezione

# Enables the Control Panel, at /admin.
admin.enabled = true
# Password to access the Control Panel. (The username is "admin".)
admin.password = admin

Nel mio caso ho scelto admin come password, riavviamo e accediamo al link http://localhost:8182/admin, inseriamo i dati accesso ed ecco il nostro pannello

Per le informazioni sulle varie funzionalità a disposizione rimando al manuale, soffermiaci su 2 schede in particolare: resolvers e processors. I processors sono gli oggetti che effettuano le trasformazioni sulle immagini e sono legate ai formati che dobbiamo gestire e gli standard supportati sono rappresentati nella scheda in una comodo tabella. La configurazione di default prevede l’uso di java2dprocessor, ma siamo liberi di fare quello che vogliamo.

I resolvers sono gli oggetti che a partire da un identificativo alfanumerico sono in grado di recuperare l’immagini. Sono presenti vari tipi, ma quello di default è il FilesystemResolver che a partire da una directory recupera l’immagine grazie al nome

Se voglio ottenere i metadati di una immagine occorre invocare l’url

http://localhost:8182/iiif/2/0001_2.jpg/info.json

dove 0001_2.jpg è il nome del file. Con tale direttiva ottengo i metadati del file in formato json

{"@context":"http://iiif.io/api/image/2/context.json","@id":"http://localhost:8182/iiif/2/0001_2.jpg","protocol":"http://iiif.io/api/image","width":9638,"height":10783,"sizes":[{"width":75,"height":84},{"width":151,"height":168},{"width":301,"height":337},{"width":602,"height":674},{"width":1205,"height":1348},{"width":2410,"height":2696},{"width":4819,"height":5392}],"tiles":[{"width":1205,"height":1348,"scaleFactors":[1,2,4,8,16,32,64,128]}],"profile":["http://iiif.io/api/image/2/level2.json",{"formats":["jpg","tif","gif","png"],"maxArea":400000000,"qualities":["bitonal","default","gray","color"],"supports":["regionByPx","sizeByW","sizeByWhListed","cors","regionSquare","sizeByDistortedWh","sizeAboveFull","canonicalLinkHeader","sizeByConfinedWh","sizeByPct","jsonldMediaType","regionByPct","rotationArbitrary","sizeByH","baseUriRedirect","rotationBy90s","profileLinkHeader","sizeByForcedWh","sizeByWh","mirroring"]}]}

Per ottenere l’immagine originale il link da invocare è il seguente

http://localhost:8182/iiif/2/0001_2.jpg/full/full/0/default.jpg

Per ottenere le varie derivate occorre variare i parametri che seguono l’identificativo del file nel rispetto delle api IIIF, per maggiori dettagli leggete le specifiche disponibili qui

org.springframework.jdbc.BadSqlGrammarException: CallableStatementCallback; bad SQL grammar [{? = call GETREPORTGENERALE(?, ?, ?, ?)}];

Comincio l’analisi del problema e la segnalazione fa pensare che l’applicativo stia invocando in modo errato la function, che effettivamente in ingresso riceve 5 parametri e non 4 come fa vedere il log. Rigenero il war pensando che sia stata installata una versione diversa ma il problema persiste. A questo punto penso che il problema possa essere lato db, pertanto rigenero gli script sql e vengono reinstallati nell’ambiente di riferimento. Niente da fare. Mi accorgo che la versione Oracle tra i 2 ambienti è differente, ma questo non dovrebbe spiegare l’errore. Non mi resta che controllare i 2 ambienti, in questo caso un tomcat 7 e mi accordo che  i 2 ambienti presentano versioni di driver oracle differenti. Il cliente aveva effettuato l’aggiornamento della versione Oracle alla 12 e di conseguenza aveva aggiornato la versione del driver Oracle, passando dalla 10 alla 12. Ecco individuato il problema, la chiamata falliva se fatta con il nuovo driver. La chiamata sfrutta la classe SimpleJdbcCall offerta da Spring

SimpleJdbcCall jdbcCall = new SimpleJdbcCall(getJdbcTemplate()).
withFunctionName("getReportGenerale").
returningResultSet("reportGenerali", new ReportMapper());

Per risolvere il problema ho dovuto modificare il sorgente, rinunciare alla SimpleJdbcCall  e utilizzare la classica CallableStatement

CallableStatement prepareCall = getConnection().prepareCall(getReportGenerale);
prepareCall.registerOutParameter(1,OracleTypes.CURSOR);

Per fortuna ci viene in soccorso il jps – Java Virtual Machine Process Status Tool che mi permette di sapere quanti processi java sono attivi e relativo PID per poterli chiudere con il comando taskkill.

Pertanto apriamo una shell e lanciamo il comando

jps -m

che mi restituirà l’elenco dei processi java attivi

984 DevMode -gen C:\Users\Valerio\eclipse-workspace-oxygen\gwtwebapp\target\.generated -war C:\Users\Valerio\eclipse-workspace-oxygen\gwtwebapp\target\gwtwebapp-1.0-SNAPSHOT -logLevel INFO -port 8888 -codeServerPort 9997 -startupUrl application.html -sourceLevel 1.8 it.valeriofinazzo.application
7876
2492 Launcher gwt:run
7308 Jps -m

A questo punto possiamo lanciare il comando taskkill /F /PID 984 e il sistema ci restituirà il messaggio

OPERAZIONE RIUSCITA: il processo con il PID 984 è stato terminato.