Differenze

Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.

--- documentazione_3di_riservata:docway4:migrazione_configurazioni [2016/01/11 18:37] – [File di configurazione vari (xml, jnlp ecc.)] aalberghini
+++ documentazione_3di_riservata:docway4:migrazione_configurazioni [Data sconosciuta] (versione attuale) – eliminata - modifica esterna (Data sconosciuta) 127.0.0.1
@@ Linea 1: / Linea 1: @@
-====== Introduzione ======
-All'interno della release 4.5.0 di DocWay4 è stato introdotto un nuovo componente: il configuratore (in attesa di trovare un nome più originale).
-Tale componente si prefigge il compito di fornire un'interfaccia unica di accesso alle configurazioni per i nostri software e, al contempo, la possibilità di specificare degli override alle singole opzioni fuori dall'applicazione.
-====== Funzionamento del configuratore ======
-Il configuratore, nell'attuale versione 1.0.0, ad ogni richiesta di una qualche configurazione da parte dell'applicativo, esegue le seguenti operazioni:
-  - cerca e carica la configurazione dall'interno dell'applicazione (considerandola come opzione di default)
-  - cerca e carica la stessa configurazione in un percorso esterno, sovrascrivendo eventuali valori omonimi caricati al punto precedente
-In questo modo, si ha a disposizione un meccanismo di override che permette di separare le opzioni di configurazione personalizzate dall'applicazione stessa, rendendo più agevoli gli aggiornamenti.
-Dato che fino alla versione 4.4.1 di DocWay4 le configurazioni erano incluse in toto all'interno dell'applicazione, è necessario spostare gli override effettuati manualmente in precedenza nel nuovo percorso di ricerca, in modo da rendere immediati anche i futuri aggiornamenti.
-===== Percorso di ricerca esterno =====
-A seconda del sistema operativo, il percorso di ricerca delle configurazioni esterno all'applicazione è il seguente:
-  * /opt/3di.it/conf/NomeApplicazione su Linux
-  * X:\3di.it\conf\NomeApplicazione su Windows ((dove X: rappresenta il drive contenente l'applicazione che sta usando il configuratore))
-È anche possibile specificare una variabile d'ambiente, TREDI_CONF_ROOT, per forzare un override del percorso di ricerca delle configurazioni (non comprendente NomeApplicazione, ovviamente). Nel caso di applicazione ospitata da Tomcat, tale variabile va specificata nel file bin/setenv.(bat|sh) oppure nel pannello di configurazione del servizio su Windows.
-====== Migrazione delle configurazioni ======
-===== File di property java (.properties) =====
-I file di property vengono cercati in base al loro nome direttamente all'interno della cartella radice della configurazione dell'applicazione, ovvero ${TREDI_CONF_ROOT}/NomeApplicazione((si usa la variable TREDI_CONF_ROOT per riferirsi al percorso fisico della cartella radice di configurazione)). Per esempio, eventuali override delle di property contenute nel file //it.highwaytech.apps.xdocway.properties//, presente nell'applicazione **DocWay4-service**, verrebbero cercati nel percorso ${TREDI_CONF_ROOT}/**DocWay4-service**///it.highwaytech.apps.xdocway.properties//.
-È possibile specificare le __singole property__ da modificare invece di riportare l'intero file modificato, in quanto esse vengono caricate e sovrascritte singolarmente.
-Per migrare configurazioni vecchie al nuovo scenario, è necessario riportare le singole property differenti da quelle di default nelle nuove posizioni sotto ${TREDI_CONF_ROOT}.
-È stato creato un semplice script per aiutare nell'estrapolare le property modificate nelle vecchie installazioni per porle nella nuova locazione sotto ${TREDI_CONF_ROOT}:
-<code bash |to-conv.sh>
-#/bin/bash
-if [ $# -ne 2 ]
-then
-	echo "Specificare file vecchio e file nuovo"
-	exit 1
-fi
-diff -au "$1" "$2"  | grep ^-[^-] | cut -d- -f2-
-</code>
-Lo script sopra riportato, fornendogli il vecchio file di property come primo argomento ed il file di property di default come secondo argomento produce in output le differenze tra i due. Tale output può essere rediretto verso l'opportuna locazione sotto ${TREDI_CONF_ROOT}.
-===== File di configurazione vari (xml, jnlp ecc.) =====
-Allo stato attuale del configuratore (versione 1.0.0), tutto ciò che non è una property è considerato un file generico "indivisibile", per cui si procede per sostituzione ovvero: se il configuratore trova un file omonimo a quello che si sta caricando dall'applicazione all'interno di ''${TREDI_CONF_ROOT}'', questo sostituisce in tutto e per tutto il file originario.
-Ad esempio, il file dei diritti di docway ''docway.xml'' contenuto nell'applicazione DocWay4-service viene cercato prima all'interno dell'applicazione nel percorso relativo ''base/acl/diritti'', poi viene cercato in ''${TREDI_CONF_ROOT}/DocWay4-service/base/acl/diritti'': se esso è presente in quest'ultimo percorso, viene caricato e fornito all'applicazione **__solo questo__**.
-====== Migrazioni specifiche per DocWay4 e DocWay4-service ======
-===== FailedEmailQueue =====
-Per far permanere tra un aggiornamento ed un altro la coda degli invii mail falliti/in corso d'opera, è necessario estrarre dalla cartella dell'applicativo DocWay4-service la cartella ''email_queue/'', ponendola sotto ''E:\3di.it\data\DocWay4-service\'' (Win) oppure ''/opt/3di.it/data/DocWay4-service/'' (Linux).
-Oltre allo spostamento della cartella, è necessario specificare nella property __failedEmailQueue.workDir__ il nuovo path (**relativo alla posizione di DocWay4-service**) della cartella email_queue.
-Solitamente, questo equivale ad impostare la property a:
-  * ''../../../../../3di.it/data/DocWay4-service/email_queue'' su Windows (poiché è necessario risalire da Programmi\Apache Software Foundation\Tomcat 7\webapps)
-  * ''../../../3di.it/data/DocWay4-service/email_queue'' su Linux (poiché è necessario risalire da apache-tomcat-7.x/webapps)
-====== Sviluppi futuri ======
-L'attuale versione del configuratore è una prima implementazione di un insieme di componenti che mirano a fornire una piattaforma per creare,gestire e fornire alle applicazioni le configurazioni delle quali necessitano.
-Eventuali sviluppi futuri potrebbero prevedere le seguenti funzionalità:
-  * caricamento "al volo" delle modifiche alle configurazioni
-  * utilizzo di un singolo manager delle configurazioni accessibile da più client contenuti nelle varie applicazioni
-  * generazione di un'interfaccia di gestione delle configurazioni