MongoDb configurazione e utilizzo ReplicaSet

In MongoDb è facilmente possibile configurare n istanze di mongod in modo da farle coordinare tra loro come repliche.
Nella replica esiste un nodo di tipo primario (PRIMARY) dove di default avvengono letture e scritture e poi ci sono dei processi asincroni che si occupano di scrivere i dati sui nodi secondari (SECONDARY).
Le applicazioni che interrogano la replica di default leggono e scrivono dal primary, per evitare di incorrere nel problema degli stale data.
Questa impostazione si può cambiare consentendo la lettura (mai la scrittura) dai secondary, ovviamente accettando il rischio di poter leggere dati non attuali.
Per configurare una replica set sono necessari 2 passi.
Per prima cosa occorre far partire le istanze dei server che faranno parte della replica. Di seguito un esempio di bat su windows:

start mongod --replSet provaReplica --logpath 1.log --dbpath c:/data/rs1 --port 27017 --smallfiles --oplogSize 64
start mongod --replSet provaReplica --logpath 2.log --dbpath c:/data/rs2 --port 27018 --smallfiles --oplogSize 64
start mongod --replSet provaReplica --logpath 3.log --dbpath c:/data/rs3 --port 27019 --smallfiles --oplogSize 64

Questa bat fa partire sul proprio server 3 istanze di mongod legate alla replica chiamata provaReplica.
Bisogna prima assicurarsi che le 3 cartelle dove le repliche scriveranno i file siano fisicamente presenti sull'hard disk.
A questo punto bisogna configurare la replica, per farlo occorre connettersi ad uno dei 3 mongod e lanciare il seguente script:

> var config={_id:"provaReplica",members:[{_id:0,host:"localhost:27017"}, {_id:1,host:"localhost:27018"}, {_id:2,host:"localhost:27019"}]};
> rs.initiate(config);

A questo punto dopo una breve attesa comparirà subito un risultato (sperabilmente un ok) e possiamo vedere come la replica sia funzionante . Digitando rs.status() abbiamo lo stato della replica.
Il server su cui ci siamo connessi facendo parte della replica può essere o un primary oppure un secondary e abbiamo comunque questa evidenza connettendoci al db vederemo la scritta provaReplica:PRIMARY oppure provaReplica:SECONDARY.
Facendo delle insert sul primary è possibile quindi testare il corretto funzionamento disconnettendosi dal primary e quindi connetendosi (mongo --port 27018 o mongo --port 27019) ai secondary per verificare che l'insert sia stato correttamente replicato.
Quando si interroga un secondario per poter effettuare le query bisogna prima dare il comando:
rs.slaveOk().
Il meccanismo di replica è reso possibile dall' oplog, una collection presente nel db local dove sono loggate le operazioni effettuate sul primary.
Tale file viene sincronizzato dal primary ai secondary consentendo la riproduzione di quanto effettuato.
Per visionare la collection uplog occorre posizionarsi sul db local e quindi digitare il comando:

db.oplog.rs.find().pretty()

Indici geospaziali con MongoDb 3.0

Con MongoDb è possibile censire in una collection una serie di luoghi identificati tramite longitudine e latitudine, secondo uno specifico formato definito GeoJson.
Quindi esistono delle funzioni di ricerca molto comode che ci consentono di farci tornare i posti più vicini oppure situati entro un certo range da una locazione.
Vediamo un esempio di script di inserimento di un luogo:

db.locations.insert({citta:"roma",nome:"viale san giovanni bosco 72", location:{type:"Point",coordinates:[12.5588865,41.8604389]},type:"Street"}

Si noti che la sintassi type:"Point" e il valore coordinates sono nomi obbligatori che corrispondono alla nomenclatura prevista dai file di tipo GeoJson.
Le coordinate vanno inserite mettendo prima la longitudine e poi la latitudine (il contrario della visualizzazione da google maps, dove si possono prendere i valori nell'url dopo la @ una volta specificato un indirizzo.

Per creare un indice di tipo geospaziale si procede in questo modo:

 db.locations.createIndex({"location":"2dsphere"})

Quindi per ricercare i punti vicini ad una coordinata si può utilizzare l'operatore $near in questo modo:

db.locations.find({location:
{$near:{$geometry:{type:"Point",coordinates:[13.4181409,41.6929645],$maxDistance:2000}}}})
.pretty()

Tomcat LDAP

Per configurare Tomcat in LDAP (es. accesso active directory) è sufficiente:

1) definire il Realm JNDI dentro il file conf/server.xml

2) mettere la web application in sicurezza via web.xml

Per recuperare lo username loggato si può utilizzare il metodo getUserPrincipal() dell'oggetto HttpServletRequest.

Per prima cosa è necessario conoscere l'indirizzo IP del nostro server Ldap. Se siamo in una intranet possiamo da dos lanciare il comando nslookup.

Per configurare il realm inserire il seguente xml (la porta di default è la 389 verificare comunque presso il proprio ambiente):

 <Realm className="org.apache.catalina.realm.JNDIRealm" 
      connectionURL="ldap://[IP]:389/" debug="99" userPattern="{0}"/>

Per il valore debug si noti che un valore alto genera un maggiore dettaglio di log. Al valore 0 corrisponde nessun log.
userPattern definisce invece il DN (Distinguished Name) .

Nel web.xml dell'applicazione web invece inseriamo il security constraint :

 <security-role>
        <role-name>*</role-name>
    </security-role>

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>
                Applicazione
            </web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>*</role-name>
        </auth-constraint>
    </security-constraint>

    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>INSERIRE CREDENZIALI ACCESSO PC</realm-name>
    </login-config>

All'utente sarà richiesto quindi di autenticarsi solo la prima volta in modalità BASIC auth, e bisognerà immettere le credenziali di accesso al pc in LAN.

Javascript usare Active-X per recuperare utente connesso

Questo script javascript (funziona soltanto su IE, non è il massimo a livello di sicurezza etc.) può essere utilizzato per recuperare lo username dell'utenza Windows connessa.

function getUserName() {
  try
  {
   var wshNetwork = new ActiveXObject("WScript.Network");
   var userName = wshNetwork.userName; 
   document.getElementById("myVal").value=userName;
   return userName;
  }
  catch(err){
   alert(err.message);
  }
 }

Sql Server 2008 fetch first n rows

Sulla versione 2008 per ottenere la limitazione dell'output si usa una scomoda sintassi di questo tipo:

SELECT * FROM ( 
  SELECT *, ROW_NUMBER() OVER (ORDER BY nomeCampo desc) as row FROM miaTabella 
 ) a WHERE a.row >0 and a.row <= 100;

Questa sintassi è analoga alla LIMIT 0,100 di MySql

Errore schemaLocation: ... must have even number of URI's

Nei file xml di spring la voce xsi:schemaLocation specifica dove trovare gli xsd per i namespace definiti prima nel file.
Esempio:

<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:jdbc="http://www.springframework.org/schema/jdbc"
 xmlns:tx="http://www.springframework.org/schema/tx"
 xmlns:batch="http://www.springframework.org/schema/batch"
 xmlns:context="http://www.springframework.org/schema/context"
 
 xsi:schemaLocation="http://www.springframework.org/schema/jdbc 
     http://www.springframework.org/schema/jdbc/spring-jdbc-4.0.xsd
  http://www.springframework.org/schema/beans 
  http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/context
  http://www.springframework.org/schema/context/spring-context-4.0.xsd">

In questo caso su alcuni namespace è definita la locazione dell'xsd (non è obbligatorio che ci siano tutti).
E' però importante che le dichiarazioni seguano questo schema [NAMESPACE] [XSD_NAMESPACE], quindi il numero totale di dichiarazioni dovrà essere pari.

Se proviamo a cancellare una di queste voci allora apparirà l'eccezione

Error schemaLocation:....... must have even number of URI's

WebSphere (su windows) controllare versione

Per controllare esattamente la versione di WAS che si sta utilizzando posizionarsi via cmd sotto

C:\Program Files\IBM\WebSphere\AppServer\bin

e lanciare la bat versionInfo.bat.

Compariranno in console tutte le info relative all'installazione di WAS