Indice

• Problems copying method. Incompatible JVM?
• casServerUrlPrefix cannot be null
• Aggancio al CAS non riuscito
• ERROR pool.ConnectionPool

Vari errori che mi sono capitati

Problems copying method. Incompatible JVM?

Si manifesta quando si vuole eseguire l’applicazione da riga di comando con

$ grails run-app

Ho trovato che il problema è la versione di Spring, avevo la 1.2.0 e in StackOverflow consigliano la 1.2.4:

$ wget https://repo.spring.io/release/org/springframework/springloaded/1.2.4.RELEASE/springloaded-1.2.4.RELEASE.jar -O springloaded-1.2.1.RELEASE.jar

casServerUrlPrefix cannot be null

Devo proteggere la mia applicazione con accesso di login e mi aggancio per questo ad un server CAS. La configurazione che ho fatto (minimale) è di inserire nel file BuildConfig.groovy, nella sezione plugins la riga

compile ":spring-security-cas:2.0.1"

Eseguendo il build:

$ grails s2-quickstart test1 Utente Ruolo Requestmap

SI verifica un errore (e Tomcat non parte)

Exception starting filter CAS Single Sign Out Filter Message: casServerUrlPrefix cannot be null.

Ora la configurazione dei parametri CAS era stata effetuata regolarmente nel file Config.groovy (tutti questi file si trovano nella cartella grails-app/conf del progetto Grails):

environments {
...
    custom {
        grails.plugin.springsecurity.cas.serverUrlPrefix="https://cas.remotesite.com/cas"
        grails.plugin.springsecurity.cas.active = true
        grails.plugin.springsecurity.cas.loginUri = "/login"
        grails.plugin.springsecurity.cas.serverUrlPrefix = "https://cas.remotesite.come/cas"
        grails.plugin.springsecurity.logout.afterLogoutUrl = "https://splashdown.remotesite.com/logout.php"
    }
...
}

E parimenti è stata fatta la configurazione del core di Spring che ometto.

Per farla breve l’errore era una ulteriore configurazione da aggiungere nel file BuildConfig.groovy: nella sezione dependencies

        compile "org.jasig.cas.client:cas-client-core:3.3.3", {
            excludes 'commons-codec', 'commons-logging', 'junit', 'log4j', 'opensaml', 'servlet-api', 'spring-beans',
                    'spring-context', 'spring-core', 'spring-test', 'xmlsec' }

Riferimenti: https://github.com/grails-plugins/grails-spring-security-cas/issues/9

Aggancio al CAS non riuscito

In questa situazione CAS viene invocato richiama l’host di ritorno passando il token di sessione, ma il client lato applicazione lo ignora e fa riferimento ad un suo db locale, un database H2.

L’url del db è scritto in DataSource.groovy ed è jdbc:h2:prodDb

ERROR pool.ConnectionPool

Mancano i driver che vanno aggiunti al file conf/BuildConfig.groovy:

    dependencies {
        // specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes e.g.
        runtime 'mysql:mysql-connector-java:5.1.27'
        // runtime 'org.postgresql:postgresql:9.3-1100-jdbc41'
        test "org.grails:grails-datastore-test-support:1.0-grails-2.3"
    }

La riga relativa a mysql di default è commentata: decommentarla. Eventualmente aggiungere il parametro di Oracle se invece si usa Oracle: si devono aggiungere i jar di odbc e ora sotto lib

marcob@jsbach[11:35:58]:betablog$ ll lib/
 totale 3140
 drwxrwxr-x  2 marcob marcob    4096 ago 26 18:07 ./
 drwxrwxr-x 15 marcob marcob    4096 ago 26 18:05 ../
 -rw-rw-r--  1 marcob marcob 1555682 ago  5 16:47 ojdbc14.jar
 -rw-rw-r--  1 marcob marcob 1646178 ago  5 16:47 orai18n.jar

Groovy è un linguaggio debolmente tipizzato (consente la definizione implicita delle variabili e l’aritmetica implicita – in cui il tipo del risultato è dato da una serie di regole quando i tipi degli addendi non sono congruenti, come illustrato tra poco) derivato da Java con in più le performance e la flessibilità di un linguaggio di scripting come Python ad esempio. È un derivato del Java con una nuova sintassi tale da renderlo molto familiare ai programmatori Java. Vi posso assicurare che dopo un po’ che lo si usa si ha la sensazione che non sia poi così tanto diverso da PHP.

Le caratteristiche di Groovy risolvono una serie di problematiche di produttività ed eleganza con un buon compromesso sulla tipizzazione.

Essenzialmente è un linguaggio “Java light” che rispetto a Java ha alcuni rilassamenti:

• Si possono definire i tipi delle variabili “in corsa” senza specificarne il tipo che viene dedotto al momento della compilazione (come avviene anche per PHP 7)
  def pi = 3.14
  e pi sarà un Float
• La tipizzazione non è rigida come con Java, praticamente scompare la differenza tra classe e tipo primitivo:
  int a=1
  equivale a
  Integer a = 1
• non sono necessari i ; alla fine dell’istruzione
• overload degli operatori per gli oggetti. Ad esempio si potrà scrivere indifferentemente l’operatore == tra due int o due Integer, o addirittura tra un int e un Integer:

int a=2            // in Java sarebbe un tipo primitivo
print(a)

Integer b=2        // in Java sarebbe una classe
print(a.equals(b)) // stampa true
print(a==b)        // stampa true

Per testare costrutti Groovy si può utilizzare la consolle che si può far partire da IDE selezionando Tools > Groovy console:

e cliccando sulla freccetta bianca in alto a sinistra si compila ed esegue il programma:

Tips on Groovy programming

Ci sono alcune pratiche utili che consentono di sviluppare in modo coerente.

Io sono partito da questa esigenza: voglio che ogni modello (o dominio come viene chiamato in Grails) debba possedere uno standard, ad esempio voglio che tutti i modelli siano corredati dai campi ch riportano lo username del creatore dell’oggetto, e i timestamp di creazione e modifica.d

Grails ha il notevole supporto ai template per ogni oggetto del paradigma MVC: dai model, ai controller alle alle view.

Per installare nella propria applicazione i template si ricorre al comando

$ grails install-templates
| Templates installed successfully
$

Questo comando semplicemente copia i template dell’installazione di Grails dentro alla cartella src/templates e si suddivide in quattro cartelle:

• artifacts che contiene i file Controller.groovy, DomainClass.groovy, Filters.groovy, …
• scaffolding che contiene le pagine gsp di layout delle views standard
• testing in cui vengono messi i test di unità
• war che contiene il package ada esportare per migrazioni ad altre istanze di Tomcat

Questo articolo è solo un abbozzo e deve essere completato.

Risorse utili

• Artifacts
• Documentazione Groovy

Da linea di comando (oppure posizionando il puntatore sopra la cartella della IDE “grails-app/domain” e scegliendo New > Grails Domain Class)

$ grails create-domain-class Contact

Grails crea la classe agenda/Contact con un po’ di default, noi la personalizziamo così

package agenda

class Contact {

    static constraints = {
    }

    String nome
    String cognome
    String azienda
    String email
    Date dataNascita

}

Poi creiamo un controller definendo come default lo scaffold (Grails crea views, metodi e orm per eseguire il CRUD di base).

Anche qui possiamo agire da linea di comando oppure, posizionandoci con il mouse sopra grails-app/controllers e scegliendo New > Grails Controller

$ grails create-controller

Anche qui personalizziamo l’artefatto:

package agenda

class ContactController {

    def scaffold = Contact

    def index() { }
}

L’unica personalizzazione è la riga 5 in cui diamo la direttiva del controller di creare metodi e viste per lo scaffold della classe Contact.

Ora si tratta di far girare l’applicazione o cliccando sul pulsantino verde in alto a destra oppure dando il comando

$ grails run-app

e puntare il browser a http://localhost:8080/agenda/

Il bello è che l’applicazione ha già una certa funzionalità di crud, infatti posso già invocare il controller cliccando su agenda.ContactController

Il Controller, a fine salvataggio mi da conferma del salvataggio:

Peccato che però la lista sia vuota

Occorre infatti configurare un supporto dati permanente, come un database. Out-of-the-box Groovy utilizza Hibernate con questa configurazione:

dataSource {
    pooled = true
    jmxExport = true
    driverClassName = "org.h2.Driver"
    username = "sa"
    password = ""
}

// environment specific settings
environments {
    development {
        dataSource {
            dbCreate = "create-drop" // one of 'create', 'create-drop', 'update', 'validate', ''
            url = "jdbc:h2:mem:devDb;MVCC=TRUE;LOCK_TIMEOUT=10000;DB_CLOSE_ON_EXIT=FALSE"
        }
    }
    test {
        dataSource {
            dbCreate = "update"
            url = "jdbc:h2:mem:testDb;MVCC=TRUE;LOCK_TIMEOUT=10000;DB_CLOSE_ON_EXIT=FALSE"
        }
    }
...
}

Ho preso spunto da Mokabyte

Un fastidioso errore 404 mi risultava dalla visita di uno dei miei siti (che utilizzano come http server nginx su sistema operativo CentOS), e mi sembrava che l’attribuzione dei permessi fosse corretta.

L’errore HTTP 404 viene emesso dal server web quando non trova nel file system la risorsa (file o cartella) corrispondente all’URI che gli viene passato dal client (ad esempio Google Chrome o Firefox): il famoso errore di Pagina non trovata.

Questo errore si verifica anche se il file c’è ma si verifica una di queste condizioni:

• l’utente sotto il quale sta girando il server non ha permessi di lettura sul file desiderato né come utente né come gruppo
• non ha la possibilità di raggiungere quella risorsa percorrendo il grafo della directory da / al file desiderato

In realtà basta infatti che una directory della catena di “cd command” (change directory) che il servizio web deve fare non sia leggibile e si verifica l’errore. Il modo più efficiente di vedere lo stato di tutta la gerarchia di directory è utilizzare il comando namei:

namei - follow a pathname until a terminal point is found

[root@websrv01 site]# namei -om /usr/share/nginx/html/
f: /usr/share/nginx/html/
 dr-xr-xr-x root     root       /
 drwxr-xr-x root     root       usr
 drwxr-xr-x root     root       share
 drwxr-xr-x root     root       nginx
 drw-rwSr-- www-data developers html

Qui è evidente il problema: tutta la catena di directory ha l’opzione x (eXecute) tranne la directory contenente la DocRoot del web server (la directory html) ragion per cui è sufficiente aggiungere questo permesso:

[root@websrv01 site]# chmod a+x /usr/share/nginx/html/
[root@websrv01 site]# namei -om /usr/share/nginx/html/
f: /usr/share/nginx/html/
 dr-xr-xr-x root      root       /
 drwxr-xr-x root      root       usr
 drwxr-xr-x root      root       share
 drwxr-xr-x root      root       nginx
 drwxrwsr-x www-data  developers html
[root@websrv01 site]# 

Il problema è risolto.

Un commento a latere dell’utilizzo del web server

Dare a root la directory pubblica del web server non è una buona prassi.

Dare indistintamente permessi di esecuzione al web server in una directory di root non è a maggior ragione una buona prassi.

Le cartelle sotto il dominio del web server vanno assegnate ad un utente specifico e a questo va dato il permesso di x.