Bettinglife

With great pleasure I can announce the release of my new Grails application: Bettinglife.
It's a betting portal (in Italian), with a comparison of the odds of many bookmakers, (Italians and Europeans).


It's in beta, but the main functionality is already there.


It can be found clicking on www.bettinglife.it

Is Groovy such terribly slow ?

A thing you hear often is that Groovy is not a good language because of its performances. Actually Groovy IS slow. Depending on the type of task, it can be from 10 - 15 times to 90 times slower than the equivalent Java version. And is usually much slower than Scala too. (By the way, Scala seems to be the hot language of the moment, what Groovy used to be 1 year ago...).
And the reason why Groovy is so slow is quite clear. To add all the metaprogramming magic, Groovy has to dispatch every method (even the ones that don't use metaprogramming) dynamically.
So, the best thing we can do is to stop using Groovy, go back to POF (Plain Old but Fast for those who love acronyms) Java and maybe start learning Scala...
Well...no.
There are a lot of reasons to keep using Groovy.
Performances are constantly improving at every new version. There is even an attempt to create a partially statically compiled version of Groovy (see the Groovy++ project). They are tryng to offer a better support to concurrency throught the introduction of the "Actors Pattern", present in languages like Scala and Erlang (see the GPars project). Maybe I will write a post on these two projects someday. So, there are a lot of efforts on this topic. And then there is a very important reason...the killer application of Groovy.
Grails.
Of course Grails is based on Groovy, and extensively uses Groovy metaprogramming capabilities: so Grails performances are not so exciting. But it will take benefit from the improving performances of Groovy. And they are also working on big improvements on the performance side. As announced in the recent Groovy and Grails Exchange, (by the way, great event!) they are working on the precompilation of the GSP, maybe one of the biggest bottleneck in Grails. The number of request per second that Grails will handle in version 1.2 will double compared with older versions. And then, is the language speed so important when your application works with databases ? And with the network ? The weakest parts are others, not the language itself. With the current version (1.1), without GSP optimization , Grails performances are already comparable with the ones of other popular web frameworks (Tapestry, Wicket, Seam). But Grails is far mor productive than most of other frameworks.

So, is Groovy a slow language ? Yes, it is. If I want to develop an performance critical application with tons of business logic and number crunching, Groovy is not my first choice. But you shall not use the same tool for every job. (and yes, the language is a tool, even if a very important one, to build applications). For other kind of applications, the boost of productivity will overcome the performance issues. Do you remember what C++ developers were saying when Java came up ?

No such property: save - Grails bug quickfix

There is a serious GORM bug affecting Grails version 1.1.1. When you try to save a domain class of a plugin or embedded in another domai class, sometimes you get a

groovy.lang.MissingPropertyException: No such property: save for class: MyDomainClass.

This bug will be fixed in Grails 1.2, but there is a quick and nasty fix: you need to add the line

MyDomainClass.get(-1)

in the BootStrap.groovy.

Using NetBeans Profiler with a Grails App

I had some problems finding out resources about how to use the NetBeans profiler with a Grails app.
NetBeans doesn't know how to attach the profiler to a Grails application, so you have to configure the Attach Mode: here is how to configure NetBeans 6.5.
- Deploy the war in the application server as usual (Tomcat for example)
- From the NetBeans menu choose: Profile > Attach Profiler...
- Click on the Attach Mode link
- Select J2EE Web app as Target Type and the application server type where the application is deployed
- Select Local as attach method and Direct as attach invocation
- Click next > next and choose auto integration
- Insert your application server install directory and your target jdk
- In the next page click the Perform button (NetBeans will change the startup script of the application server)
- Follow the instruction in the next page to start your application server (or let NetBeans start it for you)
- Click Finish and in the Profiler window click Attach

Now the profiler is attached to your application in your Application Server

Jug - Groovy Testing Techniques

Last week I made a second presentation about Groovy to the JUG Milano. It was not a continuation of the Grails tutorial I started last time ( which will be continued with a more 'hands on approach'), but was an introduction of the techniques that Groovy provides for testing Groovy and Java code. You can find the slide on Slideshare

Groovy Testing

View more presentations from Davide Rossi.

Grails and Wired.com: another success story

Another success story about the adoption of Grails for big sites was announced by SpringSource: the 'Products Review' section of the Wired.com site was entirely developed using Grails. That's another win for Grails after his adoption for the site of the UK broadcaster Sky

Jug Grails tutorial

Last week I had the great pleasure to make a brief presentation about Grails to the JUG Milano, mainly about Domain Classes and GORM. You can find the slides on Slideshare

Grails: a quick tutorial (1)

View more presentations from Davide Rossi.

Grails & Spring together...

The news is fresh, and unexpected, but big, very big for the Groovy / Grails world. G2One, the company behind Groovy and Grails technologies, was acquired by SpringSource, the company of the popular Spring framework (read the news). What does this mean for the future of Groovy and Grails ? From the technical side, Grails is build on top of Spring, so the integration between the two technologies can be more tighter in the future. Also, SpringSource can dive into the world of dynamic languages backed by a mature and fast growing technology. But the most important thing is not technical but commercial. Backed by SpringSource, Grails will enter in the arena of enterprise applications from the front door. The technology is very good for big projects, as the social network LinkedIn and UK TV broadcasting giant BskyB sites demonstrate, but is still facing a lot of resistance in big and meaningful projects, maybe because it's considered too new or not reliable...This is likely to change in the future as a result of this acquisition. Tell your boss, and to the big boys in your company...Grails is going to become mainstream...

Grails e HtmlUnit

Nei giorni scorsi ho provato a fare qualche prova di web screen-scraping in un progetto Grails, utilizzando HtmlUnit 2.3.
Dopo aver creato una applicazione Grails di prova e aver messo tutti i jar della distribuzione di HtmlUnit nella cartella lib, ho provato a lanciare l'applicazione...ottenendo come risultato solo questa bella eccezione:

Error executing script RunApp: Class org.apache.xerces.parsers.AbstractSAXParser$AttributesProxy does not implement the requested interface org.xml.sax.Attributes
java.lang.IncompatibleClassChangeError: Class org.apache.xerces.parsers.AbstractSAXParser$AttributesProxy does not implement the requested interface o
rg.xml.sax.Attributes
at groovy.util.XmlSlurper.startElement(XmlSlurper.java:305)
...

Dopo qualche ricerca e qualche tentativo ho scoperto che il problema si risolve cancellando il jar xml-apis-1.0.b2.jar dalla directory lib.

Una volta avviato il server ho potuto testare la connessione ad un sito qualunque, (http://www.daviderossi.org/ ;-) ), creando una nuova action nel controller e stampando sulla console il risultato.

Prima di poter accedere al sito, ho però dovuto configurare un proxy, in questo modo:

WebClient webClient = new WebClient(BrowserVersion.FIREFOX_2, "proxy.it", 8080)
((DefaultCredentialsProvider) webClient.getCredentialsProvider()).addProxyCredentials("user", "password");

Le possibilità offerte da HtmlUnit sono moltissime, tra cui la possibilità di trovare gli elementi per nome, id o attraverso un percorso xpath, cosi come inviare form o cliccare link...
Il primo test che ho fatto è stato di collegarmi alla home page, individuare il link alla pagina 'Tecnologie', cliccarlo e leggere il contenuto della pagina come testo.
Il codice completo della action e' questo:

def provaHome = {
WebClient webClient = new WebClient(BrowserVersion.FIREFOX_2, "proxy.it", 8080)

(DefaultCredentialsProvider)webClient.getCredentialsProvider()).addProxyCredentials("user", "password");
HtmlPage homePage = (HtmlPage) webClient.getPage('http://www.daviderossi.org/')
println homePage.getTitleText()
def xpath = "//a[.='Tecnologie']"
def link = homePage.getByXPath(xpath)?.get(0)
HtmlPage resultPage = (HtmlPage) link.click()
def content = resultPage.getElementById("content")
println content.asText()

}


Grails non invia più i form ?

Recentemente mi sono trovato davanti un problema molto strano con Grails dopo l'upgrade alla versione 1.0.3...improvvisamente il submit di un form ha smesso di funzionare, resituendomi un bel 404 page not found. A prima vista tutto sembrava a posto, l'url chiamato corretto, nessun problema. Dopo una Googolata abbastanza approfondita, ho scoperto che il problema è dovuto alla modifica dell'ordine di risoluzione dell'URL nell'url mapper di Grails 1.0.3 rispetto alle versioni precedenti.

In pratica, fino alla versione 1.0.2, per risolvere l'URL da chiamare, l'URL mapper verificava il valore del parametro action del tag <g:actionSubmit> (opzionale), se non era presente il valore del parametro action del tag <g:form> (opzionale) e infine il valore del parametro value di <g:actionSubmit>. Dalla versione 1.0.3 invece il valore del parametro value di <g:actionSubmit> ha la precedenza rispetto a action di <g:form>. Questo conporta che, nonostante l'URL mostrato sia quello del parametro action di <g:form>, Grails ricerchi invece una action con il nome del parametro value di <g:actionSubmit>, lamentandosi perchè non lo trova.

Le soluzioni possibili sono due:

1. Inserire il parametro opzionale action in <g:actionSubmit>
2. Usare al posto di <g:actionSubmit> il tag <g:submitButton> che utilizza in ogni caso la action definita in <g:form>

Maggiori dettagli si possono trovare qui:

http://www.nabble.com/behavior-change-in-1.0.3,-possible-bug:-submitAction-tag-and-URL-mapping-td17703843.html

dove tra l'altro viene spiegato che il comportamento corretto è quello attuale, cosi come il motivo per cui viene comunque mostrato l'URL dell'action di g:form...