Gwt 1.4.59-RC2 was just released. If you use Maven2 to build your project, this latest version can be found on xi8ix repository.

Here is the configuration:

<repositories>
    <repository>
        <id>xi8ix</id>
        <url>http://maven.xi8ix.org/</url>
    </repository>
</repositories>
<dependency>
    <groupId>com.google</groupId>
    <artifactId>gwt-user</artifactId>
    <version>1.4.59-RC2</version>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>com.google</groupId>
    <artifactId>gwt-servlet</artifactId>
    <version>1.4.59-RC2</version>
</dependency>

I had to tweak a few things in my SpringDispatchService. Maybe it’s time to find a more stable solution…

(3 petit pas dans l’Open-Source)

Un petit billet un peu moins technique de d’habitude sur mes premiers pas dans le monde de l’Open-Source.
C’est donc avec insouciance que je lançais à la fin avril hibernate4gwt, petite librairie de niche prenant en charge la cohabitation de deux formidables librairies à fort caractère : Hibernate (sa persistance, sa transparence… et ses proxies !) et GWT (sa simplicité, sa souplesse… et son JavaScript !).

Première surprise : on ne dépose pas un projet comme ça sur SourceForge ! Il faut avant tout en faire la demande, exposer le but de son projet, gentiment, poliment et en anglais.

Ensuite, il faut document, packager, tester. Mine de rien, cela force un peu à organiser son travail, à le formaliser d’avantage que juste un bout de code dans son coin. Au final, j’estime passer près de la moitié du temps total sur une release à ces aspects non directement productifs.

Deuxième enseignement : cela prend du temps, beaucoup de temps. Outre le travail de développement, il faut faire un peu de pub sur les groupes de discussions, surveiller les topics pour trouver ceux que votre librairie peut solutionner, répondre aux questions posées sur le forum du projet, etc…

Troisième enseignement : c’est gratifiant J’avoue que quelques mots d’encouragement, postés à la fin d’un message, un simple « thanks » me remplit de contentement. Le simple fait de savoir que des gens à travers le monde utilisent le fruit de mon labeur, que celui-ci leur évite les soucis que j’ai eu à affronter, me conforte dans l’idée que la démarche est la bonne. Et puis, j’adore lire des messages de gens dont j’ignore la nationalité du prénom

Enfin, il y a la satisfaction de poster une release dont vous êtes fier. La dernière version d’hibernate4gwt commence à ressembler à ce que j’avais en tête il y a quelques mois : transparente et légère. En mode Java 1.4, les services GWT doivent juste hériter de HibernateRemoteService pour fonctionner. Pas d’autre impact sur le code 
J’ai également rajouté le support d’objets du Domaine Java5, la demande à ce sujet étant forte (tout comme l’attente du support natif par GWT) en essayant de rester là aussi le moins intrusif possible (pas de fichier de mapping Dozer, qui d’après les retours d’expérience que j’ai, ressemblent plus à une plaie qu’à une solution).

J’ai encore un peu de pain sur la planche (supprimer les derniers héritages techniques !), mais après les efforts que m’ont demandé la dernière release, je vais faire une petite pause… le temps d’écrire un ou deux articles que j’avais promis à developpez.com (non Ricky, je n’ai pas oublié ) et de finir « Jonathan Strange et Mr. Norrell », un roman aussi prometteur qu’épais

Stay tuned !

Trying to use Maven2 to build a GWT project, here is the simplest pom.xml I came up with, starting from Xavier’s

The project can be tested in debug mode with mvn gwt:gwt. It is tested in deployed mode with mvn jetty:run-war

Don’t forget to provide the gwt-user.jar in src/main/webapp/WEB-INF/lib.

Code legend:
Blue parts depend on your project and installation path.
Red part is only needed on a Mac.
Green part makes it easier to use the Jetty plugin.

<project>
  <properties>
    <google.webtoolkit.home>
    /Users/david/Applications/java/gwt-mac-1.4.10/
    </google.webtoolkit.home>
    <google.webtoolkit.extrajvmargs>
    -XstartOnFirstThread
    </google.webtoolkit.extrajvmargs>
  </properties>

  <repositories>
      <repository>
          <id>gwt-maven</id>
          <url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo</url>
      </repository>
  </repositories>

  <pluginRepositories>
      <pluginRepository>
          <id>gwt-maven</id>
          <url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo</url>
      </pluginRepository>
  </pluginRepositories>

  <build>
    <plugins>
      <plugin>
        <groupId>org.mortbay.jetty</groupId>
        <artifactId>maven-jetty-plugin</artifactId>
      </plugin>
      <plugin>
        <groupId>com.totsp.gwt</groupId>
        <artifactId>maven-googlewebtoolkit2-plugin</artifactId>
        <version>1.5.1</version>
        <configuration>
            <logLevel>ERROR</logLevel>
            <runTarget>com.valtech.planning.Planning/JnfPage.html</runTarget>
            <compileTarget>com.valtech.planning.Planning</compileTarget>
        </configuration>
        <executions>
            <execution>
                <goals>
                    <goal>compile</goal>
                </goals>
            </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

  <dependencies>
    <dependency>
        <groupId>com.google.gwt</groupId>
        <artifactId>gwt-user</artifactId>
        <version>1.4.10</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>com.google.gwt</groupId>
        <artifactId>gwt-servlet</artifactId>
        <version>1.4.10</version>
    </dependency>
  </dependencies>
</project>

Googling for ways to integrate GWT with Spring, I didn’t find any simple solution.

Here is what I need :

• GWT RPC services should be Spring beans.
• They should be POJOs NOT extending RemoteServiceServlet.
• Mapping between Servlet paths and beans should be straightforward.

Here is what I came up with :

• It’s a very simple Servlet that receives every RPC request.
• It then gets a Spring bean by the name of the Servlet path used for the call.
• The method call to the bean is done with reflection.

public class SpringDispatchService extends RemoteServiceServlet {
    private final ClassPathXmlApplicationContext context;

    public SpringDispatchServiceImpl() {
        context=new ClassPathXmlApplicationContext(”beans.xml”);
    }

    public String processCall(String payload)
        throws SerializationException {
        try {
            Object target=context.getBean(getServletName());

            RPCRequest rpcRequest=RPC.decodeRequest(
                payload,target.getClass());
            
            Method method=rpcRequest.getMethod();
            Object[] params=rpcRequest.getParameters();

            Object result=method.invoke(target,params);
            
            return RPC.encodeResponseForSuccess(method,result);
        } catch(Throwable ex) {
            return RPC.encodeResponseForFailure(null,ex);
        }
    }
}

Avant-propos (ou le pourquoi du comment)
La sérialisation GWT répond à une règle stricte : seules quelques classes issues de la Java Runtime Environment sont supportées, et malheur à quiconque s’en écarte. De manière cohérente, certaines classes de base sont supportées. Par contre, rien n’assure que les classes dérivées le soient.
C’est justement ce comportement, au demeurant fort logique, qui est la cause de nombreuses SerializationException lors de l’envoi de date du serveur vers le client.
En effet, il est fort probable que le moteur de persistance, peu au fait des subtilités de sérialisation Javascript, aie tôt fait de remplacer votre instance de java.util.Date par une dérivation SQL (java.sql.Date ou java.sql.Timestamp) plus proche de son modèle relationnel.
Généralement, le contournement préconisé revient à créer un objet Date standard à partir de sa variation SQL afin de ne pas heurter môssieur GWT . Sauf que… la classe Timestamp est plus précise que la classe Date, et donc que cette conversion peut poser quelques problèmes de synchronisation au retour sur le serveur. Je pense notamment aux malheureux qui ont basé la gestion de version sur un champ Timestamp et qui se retrouvent bien embêtés avec leur valeur de retour tronquée…
Ce problème ayant été relevé par un utilisateur de ma librairie hibernate4gwt, j’ai décidé de m’attaquer au problème.

Portage du timestamp : premier essai
Dans ma grande naïveté (je suis parfois d’un optimisme béat), j’ai cru qu’en définissant une classe d’émulation classique _ comprenez implémentant (Is)Serializable _ le tour serait joué.
Hélas, trois fois hélas, la sérialisation JavaScript semble assez mal s’accommoder de l’héritage nécessaire entre Timestamp et Date. J’ai d’ailleurs ouvert une fiche de bug (n°1164) concernant ce problème… sans réponse à ce jour

Portage du timestamp : seconde tentative
Etant d’un naturel têtu, j’ai parcouru les sources de GWT à la recherche du mécanisme permettant la sérialisation de l’objet java.util.Date.
En fait, un objet émulé nécessite deux classes :

• Une classe d’émulation JSNI, situé dans le dossier ‘com/google/gwt/emul/<package-emulé>’ ou un de vos répertoires propre en suivant la même nomenclature
• Un serialiseur dédié, portant le même nom que la classe, agrémenté de « _CustomFieldSerializer ».

L’écriture de la classe d’émulation JSNI s’est avéré relativement simple, en m’appuyant sur l’existant Date, seul le champ « nanoseconds » devant être ajouté.

Le sérialiseur quand à lui répond à un certain nombre de règles plus ou moins tacites (il n’existe pas d’interface à implémenter) :

• Il doit être situé soit au même niveau que la classe concernée, soit dans le package ‘com.google.gwt.user.client.rpc.core.<package.émulé>’
• Il doit implémenter les méthodes « serialize » et « deserialize », celles-ci prenant en charge le type associé.
• Si la classe associée n’a pas de constructeur vide, l’interface doit prendre en charge la construction de l’instance par le biais de la méthode « instantiate »
• Bien entendu, les appels à la sérialisation et à la désérialisation doivent s’effectuer dans le même ordre, sous peine de mauvaise surprise

public final class Timestamp_CustomFieldSerializer
{
  public static void deserialize(SerializationStreamReader streamReader,
			         Timestamp instance)
                                 throws SerializationException
  {
    // no fields
  }

  public static Timestamp instantiate(SerializationStreamReader streamReader)
                                      throws SerializationException
  {
    Timestamp instance =  new Timestamp(streamReader.readLong());
    instance.setNanos(streamReader.readInt());

    return instance;
  }

  public static void serialize(SerializationStreamWriter streamWriter,
	                       Timestamp instance)
                               throws SerializationException
  {
    streamWriter.writeLong(instance.getTime());
    streamWriter.writeInt(instance.getNanos());
  }
}

Notez bien que les méthodes utilisent et renvoie des objets de type Timestamp et non de simples objets, ce qui explique qu’il n’y ait pas d’interface générique à implémenter.
Et ça marche !

Dernière remarque : concernant le portage en Javascript d’une classe existante, c’est cette dernière qui est utilisée en Hosted Mode, et qu’il faut déployer l’application GWT en mode Web pour voir s’exécuter le code JSNI et valider son fonctionnement.

GWT au pays des Bisounours
Sentez-vous ce parfum d’euphorie un brin béat qui traverse le web à la seule évocation de GWT, cette propension à parer de qualités la librairie de Google parfois au mépris de toute objectivité ? Ressentez-vous à la lecture des différents articles de présentation l’ombre de ce doute face à cette librairie, dont on vous promet monts et merveille sans contrepartie ? Parfaite intégration avec l’existant, productivité multipliée par 5, la fin des migraines Javascript ? Se peut-il vraiment que tout soit aussi parfait ?
Non, bien sûr que non…
J’avoue ne pas être d’un nature très « groupie », et donc que les superlatifs provoque en moi au mieux un haussement de sourcil interrogateur, et bien plus souvent un réaction de méfiance face au merveilleux que l’on me promet.
Soyons clairs : je pense, je suis persuadé que GWT est une bonne librairie, un très bon outil. Pas moins. Pas plus non plus. En effet, elle résout nombre de problématiques liées aux développements Ajax et Web 2.0.
De là à dire qu’elle ne souffre d’aucun défaut, il y a un pas que je me refuse à franchir. Explication en détail…

Le syndrome de la librairie magique
Comme toute nouvelle librairie, les avantages de GWT ont tendance à en cacher les limites. Souvenez-vous du précédent « Hibernate » : l’accès aux bases de données devenait tellement plus simple que l’on a cru, à tort, que la gestion de la persistance se ferait sans mal, et mieux, sans avoir besoin de comprendre les mécanismes sous-jacents tels que transactions, jointures et accès concurrents.
On assiste ici au même phénomène : la création d’application Ajax est rendu tellement plus abordable avec GWT que l’analyse s’en arrête aux bienfaits sans en mesurer les coûts et les pièges. Ne vous faites pas d’illusion : une connaissance, même partielle, de Javascript et des mécanismes associés reste nécessaire pour éviter toute déconvenue.
A mon avis, GWT, tout comme Hibernate ou Java en son temps, résout 80% des problèmes, mais crée 20% de problématiques nouvelles et complètement inédites qu’il serait malhonnête d’ignorer ou de passer sous silence.

Le mythe de l’intégration avec l’existant
L’un des arguments les moins recevable pour le modeste auteur d’hibernate4gwt que je suis est de dire que GWT fonctionne sans peine avec les applications existantes.
C’est bien entendu parfaitement faux avec toute application Spring-Hibernate (pour rester sur des technos éprouvées).
Le simple fait que GWT ne supporte que la syntaxe Java 1.4 pour la partie JavaScript de l’application interdit d’utiliser annotations et collections typées, pourtant largement répandues dans nos applications. Il en découle l’impossibilité pure et simple d’utiliser les entités du Domaine dans la partie cliente d’une application GWT.
Face à ce problème, la communauté se contente pour l’instant de pis-aller. La plus répandue consiste à convertir les entités du modèle en DTO (data transfer objects) par l’entremise de Dozer, ce qui implique l’apprentissage d’une nouvelle librairie et l’écriture des fichiers de mapping idoines. Avouez que pour une intégration naturelle, on peut repasser…

Et encore, je vous fais grâce des problématiques propres à la coexistence des entités Hibernate avec GWT . Pour plus d’info sur ce sujet, je vous renvoie au site web d’hibernate4gwt, où j’ai posté un article sur le sujet…

Une documentation anémique
A la différence d’Hibernate ou de Spring, deux poids lourds de l’Open-Source cités plus haut, GWT ne bénéficie que d’une documentation, disons, sommaire. Quelques pages web couvrant les cas standard, mais rien concernant de manière exhaustive le fonctionnement de la librairie.
C’est d’autant plus gênant que cette librairie contient de nombreux concepts innovants qu’il conviendrait de mieux documenter (je pense notamment aux Serializer et aux Generators) afin d’en encourager l’adoption, l’usage et l’enrichissement.
Heureusement, quelques passionnés, tel Robert Hanson, ont pris le taureau par les cornes et entrepris un large travail de vulgarisation que ce soit sur leur site web (dont Timepedia est sans doute l’un des meilleurs exemples) ou par le biais de livres (le célèbre et pour l’instant relativement unique « GWT in action »), mais cela peut difficilement avoir la valeur d’un manuel de référence estampillé « officiel », nécessaire à l’adoption par le plus grand nombre.

Dans la jungle des widgets
Les composants graphiques GWT affichent une situation paradoxale : le framework en lui-même en propose relativement peu (cf. Kitchen Sink, la démo “officielle” GWT), et les librairies de composants tierces (Open-Source ou non) sont pléthores.
Pourtant, autant on peut faire confiance au caractère professionnel des widgets natifs GWT, autant on est en droit de s’interroger concernant les autres composants : quelle est leur fiabilité ? Leur pérennité ? Gèrent-ils convenablement l’arbre DOM ?
Bref, des interrogations que l’on ne peut évacuer d’un simple haussement d’épaule et qui demanderait une évaluation minutieuse, ou l’émergence d’un standard de fait, ce qui ne semble pas encore le cas.

Programmation graphique : un pas en avant, un pas en arrière ?
Avec sa programmation entièrement en Java et événementielle, GWT nous renvoie un peu à l’ère de Swing, avec ses avantages et ses inconvénients.
Au rayon des premiers, la programmation graphique retrouve enfin son unité, face aux innombrables lnagages nécessaires à une page JSF-Ajax (HTML, JSP, JSTL, Javascript,…)
Concernant les défauts, on notera la fin de la séparation entre design et programmation, tel qu’il avait été introduit justement avec les JSP/JSF.
Plus important, GWT n’est pas structurant en terme de programmation. Il n’existe pas à ce jour de framework standardisant la programmation d’une action, ou les règles de navigation, à la manière d’un Struts en son temps…
Du coup, chaque développeur a l’embarras du choix pour coder le comportement de son application, et au vue du forum officiel, nombreux sont ceux qui sont embarrassés par ce choix . De plus, les projets y perdent en homogénéité, et donc le retour d’expérience sur telle ou telle pratique sont plus lents.

Conclusion
Ces manques, ces défauts, ne doivent pas vous faire perdre de vue mon propos premier : GWT est un très bon outil, sans doute le meilleur disponible concernant le développement d’application Ajax.
Mais au milieu de toute cette vague d’enthousiasme parfois sans recul, il me semblait important de ramener GWT à un juste statut : celui d’une librairie, utile et productive certes, mais dont l’adoption ne se fera pas sans impact…

Juste quelques mots pour vous annoncer la version 0.1 de hibernate4gwt (previously LazyKiller ), hébergée sur SourceForge.

La solution à base de DTO Dozer ne me satisfaisant pas, j’ai décidé de publier mon code sous licence Open-Source, en espérant ainsi faire avancer le débat et simplifier la vie de mes confrères.

Pour information, je travaille en ce moment sur la V0.2 qui devrait permettre (en mode stateful dans un premier temps) de ne plus avoir besoin de l’héritage technique courant.

Hope this helps !

Foreword : why english ?
In my opinion, a technical tip must be written in english to be useful to most people (not only French one). The design and architectures entries, which are longer and more complex, will probably stay in French, since I am not always very comfortable (as you will probably see it) with William Shakespeare’s language

Introduction
Acegi is a powerful security framework based on Spring that allows you to simply manage authentication and authorization.

You can find a lot of very good written tutorials on the web (like this one)

Working with GWT
Acegi works pretty well with GWT. Both the main HTML page and RPC call are filtered by the Security library with a simple configuration file.
In my opinion, the simplest way to integrate Acegi is to not manage the login page in your module, but in a separate HTML file (no need for a new GWT module!) like this one:

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html">
    <title>My Login Page</title>
  </head>
  <body>
    <h2>Please log in</h2><br>
    <form method="POST" action="j_acegi_security_check">
      Username: <input type="text" name="j_username"><br>
      Password: <input type="password" name="j_password"><br>
      <input type="submit" value="Log in >>">
    </form>
  </body>
</html>

I have noticed only two issues, since GWT is an Ajax framework and Acegi is designed for pages applications (like JSF): session expiration and identification for unit testing.

Session expiration
Ajax applications are not classic HTML applications: the whole page is neither reloaded nor redirected to a new one. Consequently, when HTTP session expires (by default, after 30 minutes), any subsequent RPC call will fail and your application will receive… the HTML login page as error cause !

The best way is to properly handle the failure exception in your AsyncCallback for example by parsing the error message:

public void onFailure(Throwable caught)
{
	String errorMessage = caught.toString();
	if (errorMessage.indexOf("403") != -1)
	{
	//	Access denied for this role
	//
		Window.alert("Access denied");
	}
	else if (errorMessage.indexOf("Login") != -1)
	{
	//	Session expired : display login form
	//
		LoginDialog.show();
	}
	else
	{
	//	Other error
	//
		Window.alert("Error : " + errorMessage);
	}
}

The login modal dialog allows the user to near seamlessly continue his navigation in the application.
Of course, you can factorize this code in a clean abstract class

Testing

Finally, GWT implements a test unit framework, based on JUnit. It permits you to test the behaviour of the client code, including asynchronous RPC calls (cf the relevant documentation). Nevertheless, the GWT TestCase has one serious limitation: since the test code is compiled in JavaScript, it must be “GWT-JRE compliant”. That means that you cannot call any third party code in you GWT test, and especially Acegi TestAuthenticationProvider.
The only way I found to make it works is to call the authentication form from the test case, throught Java Script Native Interface:

/**
 * Log on Acegi with GWT
 */
protected static native void login(String user,
                                   String password)/*-{
    $wnd.open("j_acegi_security_check?j_username="+
              user+"&j_password="+password, "login");
    }-*/;

Every test case method must then call the loginAs method at the very beginning of its execution.

public void testSearchAgent()
{
    login("admin", "admin");
     …
}

It stills open an empty browser window, but the Unit test is then authenticated.

Last tip…
If you want to launch your GWT unit test from Eclipse, don’t forget to add your ‘test’ folder as source directory in the <Module>.gwt.xml file and to add the ‘src’ and ‘test’ folders in the classpath of the JUnit test (Run… ->Classpath->Advanced…->Add folder…)

GWT peut-il survivre sans Hibernate ?
Lors de nos débats actuels (vous savez, ces longues palabres techniques et enflammées où chacun campe sur ses positions ) sur la libraire Google, la gestion des proxy Hibernate a une place de choix.
Au-delà des octets se pose une question de fond : à quel point une librairie émergeante doit-elle supporter des standard de marché pour être s’imposer ?
Attardons-nous quelques instants sur la question.
Son sens n’est pas de savoir si une nouvelle librairie doit fonctionner avec les milliers de lignes de code existantes de par le monde. Il semble relativement évident que toute nouvelle technologie qui nécessiterait de faire table rase de l’existant, tant au niveau formation que code produit, serait vouée à l’échec, si géniale soit-elle. Les enjeux économiques autorisent une évolution technique, pas une révolution.

Non, l’élément important est plutôt de savoir à quel point elle devrait être compatible avec l’existant… La gestion des proxies en est une assez bonne illustration : GWT doit-elle les prendre en charge, en sérialisant les objets Hibernate en JavaScript ?
Pour ma part, j’y vois plusieurs objections :

• Il ne me semble pas du ressort d’une librairie de présentation de gérer les artefacts de sa consœur qui gère l’accès aux données
• Pourquoi supporter Hibernate, et pas TopLink, JDO, Spring, JackRabbit, [insérez ici votre librairie préférée], … ?
• Le mécanisme de proxies n’est pas standardisé. Non seulement un tel développement serait donc spécifique à Hibernate, mais il serait lié à une implémentation particulière (version) de la librairie de persistance !

Inversons maintenant la question : Hibernate doit-il supporter GWT ? En fait, je trouverai assez naturel qu’Hibernate propose un mécanisme de « déproxification » des objets qu’il gère, pour répondre au besoin des Objets qui transitent entre plusieurs machines virtuelles. Cela recouvre à la fois le cas de GWT (si on considère que la librairie fonctionne sur une machine virtuelle Java écrite en JavaScript), mais aussi la sérialisation/désérialisation XML ou l’envoi sur JMS.

Au final, il est probable que GWT et Hibernate continuent à évoluer dans leurs sphères respectives. La « glue » entre l’un et l’autre reste pour l’instant une problématique à la charge de l’application. Nul doute que l’usage fera émerger rapidement de bonnes pratiques qui permettront de marier efficacement deux technologies majeures mais qui ont parfois du mal à cohabiter.

LazyKiller : le retour
Et pourtant, tout n’est pas perdu ! J’ai mis au point une petite librairie (en fait, plutôt une preuve de concept) permettant d’utiliser des objets du Domaine Hibernate partiellement chargé dans la couche de présentation GWT (et de les réinjecter dans le code serveur).
Pour les plus courageux d’entre vous, j’ai écrit un long article qui explique les problèmatiques rencontrées, celles résolues et les limitations actuelles. Bonne lecture !

“ou comment Eclipse valide le comportement de GWT”

A quoi reconnaît-on une bonne idée ? Au nombre de copies qu’elle génère

Eclipse mets en avant sa Rich Ajax Platform, en réalité plus proche d’Echo2 que de GWT : à chaque action utilisateur, le serveur est sollicité via Ajax et renvoie au navigateur le code de présentation. En fait, l’idée maitresse semble ici d’étendre SWT au client léger.

Le gros avantage de RAP (tout comme Echo2) est l’utilisation possible de tout le JDK sans restriction. Par contre, la sollication systématique du serveur me semble le point faible de la solution…

Au delà de son succès éventuel, L’apparition (ou du moins la confirmation) de cette librairie tend en tout cas à démontrer que les jours des développements JavaScript sont comptés, et que l’encapsulation Java du code client sera bientôt la norme, avec GWT ou un autre…

Une vraie bonne nouvelle en quelque sorte !