• What’s new in Groovy 1.8, and What’s cooking in 1.9!

Nous avons également eu le droit à une présentation animée par Stéphane Maldini en seconde partie introduisant les nouvelles fonctionnalités de Grails 1.4, et il faut bien avouer que cette nouvelle version va envoyer du lourd au niveau killer features. Grails dans sa version 1.4 va proposer de nombreuses fonctions avancées particulièrement tournées vers la productivité.

Quelques liens intéressants concernant Grails 1.4 :

• Grails Roadmap
• Nouveautés Grails 1.4 concernant le support des tests
• Grails 1.4.0.M1 est déjà disponible!
• Un billet intéressant comparant les prerformances de Grails à d’autres frameworks web

J’ai eu l’occasion de fricoter avec quelques uns d’entre eux (CVS, Subversion, Mercurial ou bien encore ClearCase). Pendant un temps Subversion semblait être l’outil incontournable. Comme on dit la roue tourne, aujourd’hui l’outil au top c’est Git.

Pour avoir joué un peu avec, on peut considérer que Git est très semblable à Mercurial puisque ces deux outils de gestion de source sont de type DVSC. Cependant je n’avais jamais eu l’occasion d’étudier Git plus en profondeur. C’est maintenant c’est chose faire grâce à la présentation de Sébastien Douche ( @sdouche ) au ParisJug d’avril.

Si vous avez manqué la présentation, je vous invite à aller lire le blog de #gitfr. Le blog est très complet et reprend un certain nombre de thèmes abordés pendant la présentation. Il semble que la présentation devrait être rejouée d’ici une dizaine de jours. L’annonce devrait être faite sur le site du ParisJug. Je vous encourage chaudement  à y assister si vous en avez l’occasion, d’autant plus si vous en avez marre de Subversion, puisque vous aurez l’occasion d’assister à un enterrement en règle de notre bon vieux Scm.

A l’occasion de cette sortie, j’ai rédigé un billet de présentation de Cloud Foundry sur le blog de Xebia. Si vous être curieux de ce qui peut se faire aujourd’hui en terme d’offre PaaS, je vous invite à aller lire mon article à l’adresse suivante:

• http://blog.xebia.fr/2011/04/13/lancement-du-projet-platform-as-a-service-cloud-foundry-de-spring-source/

En vrac, et pour teaser, SpringSource/VMware propose ni plus ni moins qu’une plateforme Cloud multi-langage: Java, Ruby, JavaScript, et autre langages de la JVM. Dans la foulée la plateforme propose différents supports de stockage de données: Redis (Base Clés/valeurs), MongoDB (Base Document), MySql (Base relationnelle). Il est par exemple possible de créer son application Web avec des frameworks tels que Rails, Grails ou bien encore avec Node.JS.

Tout cela, est bien alléchant et donne envie d’aller essayer cette offre. A côté de cela, il ne faut pas oublier que SpringSource/VMware propose également en preview une offre Dev at Cloud nommée Code2Cloud (Git, BugTracker, Hudson, …), ainsi qu’une suite logicielle basée sur Eclipse nommée STS (Spring Tool Suite) permettant d’exploiter parfaitement tous les produit SpringSource/VMware.

Aucun prix n’a pour le moment été communiqué, l’essai de la beta de la plateforme est pour le moment gratuit, mais l’attente d’activation de son compte semble longue. Vous pouvez toujours vous lancer dans le développer d’une application basée sur l’offre de SpringSource/VMware, en démarrant un projet avec STS. Une belle introduction est proposée aux URL suivantes:

• http://blog.springsource.com/2011/04/12/cloud-foundry-for-spring-developers/
• http://blog.springsource.com/2011/04/13/using-cloud-foundry-from-sts/

Pour cela, il vous suffit d’aller dans le menu “Pomme”, puis dans les “Préférence Système”. Une fois la fenêtre ouverte, rendez-vous dans le menu “Sécurité” (Première ligne), puis assurez-vous que l’option: “Exigez le mot de passe …” est sélectionnée. Enfin, choisissez dans la liste déroulante la valeur: “Immédiatement”.

Vous êtes maintenant prêt pour utiliser un raccourci clavier pour locker votre PC… Pardon votre Mac. Il ne nous manques plus que ce fameux précieux pour activer la fonction lock de votre Mac. Pour cela, il vous suffit d’appuyer sur la combinaison de touches suivante: “Shift+Ctrl+Eject”. Vous économiserez au passage votre batterie et sauverez les ours blancs puisque l’écran se met en veille dans la foulée.

Mobl est un langage compilé et typé statiquement, il est prévu pour être utilisé travers un plugin Eclipse. Le plugin propose la coloration syntaxique, l’affichage d’erreurs, la résolution de références et la complétion de code. Le compilateur mobl (intégré à l’IDE) compile les modules mobl en une combinaison de fichiers HTML, JavaScript et CSS à chaque sauvegarde.

Les application mobl ne reposent pas sur une technologie serveur particulière, elle repose uniquement sur une gestion cliente de l’application. Le langage supporte les appels de services web JSON asynchrones.

Le langage mobl propose différentes fonctionnalités permettant d’améliorer la productivité des développeurs mobiles:

– Interfaces utilisateur spécifiées de façon déclarative.
– Gestion de la persistance de données transparantes via la déclaration d’entités. Les objets sont automatiquement sauvés en base de données, et peuvent être lues sans besoin de requêtage SQL.
– Statique en principe, le typage peut être dynamiquement typé. Le typage statique permet à l’IDe la détection rapides d’erreurs, la résolution de références, et la complétion de code. Grâce à l’inférence de type, dans la plupart des cas, il n’y a pas de besoin de déclaration explicite de types. Le type Dynamic permet l’utilisation de notions d’accès à des propriétés et méthodes de façon dynamique.
- Un scripting rédigé dans un style d’appel synchrone automatiquement transformé en appels asynchrones.

Tout ça donne l’eau à la bouche, et invite à aller creuser un peu plus ce DSL. Pour cela, je vous invite à aller jeter un coup d’oeil à l’article InfoQ qui en propose une bonne présentation/introduction: http://www.infoq.com/articles/Mobl

A quand un DSL facile et rapide à utiliser pour générer un site web mobile en Java? Bien oui, il faut bien satisfaire les java dependants ;)

Mobl propose entre autre des exemples permettant de générer des sites mobiles basés sur jQueryMobile et Sensha Touch

* Le site internet du langage: http://www.mobl-lang.org/

On peut déjà y trouver une bonne trentaine d’exemples de site mobiles qui pourront sûrement vous aider à vous donner un bon aperçu de ce vous pouvez faire avec jQueryMobile. Un coup d’oeil au code source vous aidera à mettre rapidement le pied à l’étrier si vous souhaitez créer votre propre site mobile.

Vous pouvez visiter la galerie à l’adresse suivante: http://www.jqmgallery.com

Les changements principaux de cette version concernent une réécriture complète du support Ajax fournissant une API encore plus efficace et consistante, et l’intégration d’un mécanisme qui permet de chaîner différents callbacks sur des appels de fonctions qu’ils soient asynchrones ou non.

L’API Ajax fournit maintenant un object jqXHR retourné par l’appel de la méthode jQuery.ajax() qui permet de gérer de façon consistante l’objet XMLHttpRequest quelque soit la plateforme utilisée. Par exemple, il est maintenant possible d’annuler facilement une requête JSONP ce qui n’était pas le cas auparavant.

// Assign handlers immediately after making the request,
// and remember the jxhr object for this request
var jxhr = $.ajax({ url: "example.php" })
.success(function() { alert("success"); })
.error(function() { alert("error"); })
.complete(function() { alert("complete"); });

// perform other work here ...

// Set another completion function for the request above
jxhr.complete(function(){ alert("second complete"); });

Une explication complète du mécanisme appelé: ‘Deferred Objects‘ est disponible sur le site de jQuery.

jQuery expose maintenant, par le biais de la méthode jQuery.sub() un moyen simple de créer et modifier un clone de jQuery dans la même page sans pour autant interférer avec la déclaration par défaut. il est ainsi possible d’overrider des méthodes natives jQuery sans craindre d’incompatibilité avec d’autres scripts d’une même page basée sur jQuery. Cela rend aisé l’écriture d’API basées sur jQuery sans risquer une collision de namespaces.

(function(){
var sub$ = jQuery.sub();

sub$.fn.myCustomMethod = function(){
      return 'just for me';
    };

sub$(document).ready(function() {
      sub$('body').myCustomMethod() // 'just for me'
    });
})();

typeof jQuery('body').myCustomMethod // undefined

Cette version inclut également des améliorations de performance puisque la gestion de certaines méthodes de traversée de l’arbre DOM ont largement été optimisées comme les méthodes: .children(), .prev(), and .next(). Ces améliorations sont particulièrement importantes sous webkit (Chrome et Safari), mais elles sont également intéressantes sous Internet Explorer, puisqu’elles permettent de faire décoller un peu les performances de notre cher navigateur.

A ce jour quelques 4500 tests passent avec succès sur un nombre impressionnant de browsers (dont IE6, mais également Firebox 4 beta), ce qui pousse au respect au vue de l’hétérogénéité de ce joyeux petit monde.

Pour finir sur une note intéressante, le système de build de jQuery est maintenant basé sur l’environnement serveur JavaScript: NodeJS, ce qui est plutôt original, mais qui permet au navigateur de réduire sa dépendance envers Java/Rhino, et de se tourner vers de nouvelles solutions JavaScript innovantes.

Une road map de la librairie est disponible à l’adresse suivante: http://docs.jquery.com/Roadmap.

Presque 3 longs mois après la sortie de la version précédente, jQuery Mobile vient de sortir sa troisième version alpha, accompagnant à une semaine d’intervalle la release de son grand frère jQuery en version 1.5.0. L’attente ne fut pas vaine, puisque de nombreuses améliorations sont au rendez-vous:

• Quelques 150 bugs fixés, environs 250 nouveaux tests unitaires
• Une amélioration substantielle de la navigation et du core de la librairie
• Un support de première classe pour de nouveaux browsers mobiles: Firefox Mobile (Fennec), Opera Mobile / Mini. Un support de première classe est également proche pour les plateformes Windows Phone 7 et Nokia.
• Un support amélioré des browsers des plateformes iOS, Android, BlackBerry 6, Palm WebOS, et de nose browsers de bureau.
• La prise en charge d’un date picker, non packagé dans la version. La prise en charge de nouveaux composants devrait arriver dans les prochaines versions (Progress Bar, Spinner, Time Picket)
• La prise en charge du clavier a été améliorée et permet de mieux simuler un comportement natif au sein du navigateur.
• De très nombreuses autres améliorations ont été intégrées à cette version. Une liste exhaustive peut être trouvée sur le blog de jQuery Mobile.

Ce qu’il faut retenir également, c’est l’annonce d’une bêta dans le mois qui va suivre, puis la sortie de la release 1.0 dans la foulée. Les objectifs fixés sont d’améliorer les performances générales de la librairie,
d’améliorer l’expérience utilisateur et la réactivité, et de fournir un support à un nombre plus important de browsers et plateformes mobiles. Bien que le sujet ne soit pas vraiment abordé dans le billet de l’annonce de cette sortie, on devrait également voir dans un avenir proche, une meilleure prise en charge de nos chères tablettes: iPad, PlayBook, et compagnie (après la sortie de la 1.0 ?).

Bien que l’annonce de cette release soit réjouissante pour le monde des développeurs mobiles, il n’en reste pas moins vrai que le niveau de performance souffre encore fortement la comparaison avec les applications natives (Gestion de liste), et la gestion de la navigation entre les différents écrans présente encore quelques dysfonctionnements. Il n’y a pas de doute que ce type de défauts seront rapidement gommés avec la sortie des prochaines versions.

Vous pouvez retrouvez ces informations sur le site de jQuery Mobile, leur blog et les suivre sur twitter via le compte: @jquerymobile.

A ce stade de notre développement nous sommes déjà en mesure d’utiliser pleinement notre composant, mais nous ne pouvons pas encore en assurer sa qualité. Pour cela, il est nécessaire d’ajouter à notre composant différentes classes de test. Bien que la testabilité de frameworks d’intégration puisse parfois paraître difficile, le projet Apache Camel fournit tous les outils nécessaires permettant de répondre à ce besoin. Nous verrons donc dans cet article comment tester le composant que nous avons développé.

Pour finir, nous verrons comment intégrer notre développement à un projet Camel, ainsi que les limites de notre composant et les solutions pour résoudre ces limitations.

Tester la classe ApnsConsumer

Bien que le projet Apache Camel permette de travailler naturellement avec Spring, nous nous attarderons dans un premier temps sur les méthodes permettant de tester notre composant sur un mode standalone. Pour cela, nous étendrons la classe CamelTestSupport. Cette dernière fournit les méthodes nécessaires pour effectuer différentes assertions sur les valeurs attendues en fin de traitement, en particulier sur des endpoints de type MockEndpoint.

Nous devons tout d’abord implémenter les 2 méthodes suivantes:

Avant l’exécution de nos tests, un serveur APNS bouchonné doit être lancé. Il enverra sur le flux feedback des données factices.

L’objectif de ce test est de valider que le endpoint apns:consumer est capable de consommer les informations de test renvoyées par le flux feedback du serveur bouchonné. Le endpoint Camel mock:result nous permet de valider les assertions nécessaires sur les messages reçus par ce endpoint.

Le endpoint apns:consumer est configuré pour poller le flux feedback de l’APNS toutes les 500ms. Le test ne doit donc pas durer raisonnablement plus de 5 secondes en tenant compte du temps d’attente d’une seconde avant les assertions et du temps de démarrage du serveur bouchon APNS. Un timeout de 5 secondes est donc placé sur le test pour s’assurer que ce dernier tombe en erreur si un événement bloquant inattendu empêche le test de se terminer.

public class ApnsConsumerTest extends CamelTestSupport {

    ApnsServerStub server;

    public ApnsConsumerTest() {
    	super();
    }

    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() throws InterruptedException {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }

    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }

    /**
     * Test de l'ApnsConsumer. L'objectif est de vérifier que le flux feedback est
     * bien consommé par la route Camel. Pour cela on vérifie après consommation
     * que le endpoint MockEndpoint a bien reçu les messages.
     */
    @Test(timeout=5000)
    public void testConsumer() throws Exception {

    	byte[] deviceTokenBytes = ApnsUtils.createRandomDeviceTokenBytes();
        String deviceToken = ApnsUtils.encodeHexToken(deviceTokenBytes);

        MockEndpoint mock = getMockEndpoint("mock:result");
        mock.expectedMessageCount(1);
        mock.message(0).body().isInstanceOf(InactiveDevice.class);

        byte[] feedBackBytes = ApnsUtils.generateFeedbackBytes(deviceTokenBytes);
        server.toSend.write(feedBackBytes);

        Thread.sleep(1000);

        assertMockEndpointsSatisfied();

        InactiveDevice inactiveDevice = (InactiveDevice)mock.getExchanges().get(0).getIn().getBody();
        assertNotNull(inactiveDevice);
        assertNotNull(inactiveDevice.getDate());
        assertNotNull(inactiveDevice.getDeviceToken());
        assertEquals(deviceToken, inactiveDevice.getDeviceToken());
    }

    /**
     * Création et configuration du contexte Camel avec une configuration de test.
     * Enregistrement du composant APNS, et configuration de l'ApnsService
     */
    protected CamelContext createCamelContext() throws Exception {
        CamelContext camelContext = super.createCamelContext();

        ApnsServiceFactory apnsServiceFactory = ApnsUtils.createDefaultTestConfiguration();
        ApnsService apnsService = apnsServiceFactory.getApnsService();

        ApnsComponent apnsComponent = new ApnsComponent(apnsService);

        camelContext.addComponent("apns", apnsComponent);

        return camelContext;
    }

    /**
     * Création de la route Camel permettant de simuler la consommation du flux
     * feedback de l'APNS
     */
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from("apns:consumer?initialDelay=500&delay=500&timeUnit=MILLISECONDS")
                	.to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
                	.to("mock:result");
            }
        };
    }

}

Tester la classe ApnsProducer

De la même façon que nous nous y sommes pris pour la classe de test ApnsConsumerTest, nous allons étendre la classe CamelTestSupport pour tester notre classe ApnsProducer. L’objectif est de vérifier que le serveur bouchonné reçoit bien les messages produits.

public class ApnsProducerTest extends CamelTestSupport {

    private ApnsServerStub server;
    private String FAKE_TOKEN = "19308314834701ACD8313AEBD92AEFDE192120371FE13982392831701318B943";

    public ApnsProducerTest() {
    	super();
    }

    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }

    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }

    /**
     * Test de l'ApnsProducer. L'objectif est de vérifier que le serveur APNS a
     * bien reçu les notifications envoyées.
     * Pour cela on vérifie après production des notifications que le serveur bouchonné
     * a bien reçu les messages: On s'assure que les tableaux de bytes de la notification
     * produite et du contenu reçu par le serveur sont bien égaux.
     */
    @Test(timeout=2000)
    public void testProducer() throws Exception {
    	String message = "Hello World";
    	String messagePayload = APNS.newPayload().alertBody(message).build();

        ApnsNotification apnsNotification = new ApnsNotification(FAKE_TOKEN, messagePayload);
        server.stopAt(apnsNotification.length());

        template.sendBody("direct:test", message);

        server.messages.acquire();
        assertArrayEquals(apnsNotification.marshall(), server.received.toByteArray());
    }

    /**
     * Création et configuration du contexte Camel avec une configuration de test.
     * Enregistrement du composant APNS, et configuration de l'ApnsService
     */
    protected CamelContext createCamelContext() throws Exception {
        CamelContext camelContext = super.createCamelContext();

        ApnsServiceFactory apnsServiceFactory = ApnsUtils.createDefaultTestConfiguration();
        ApnsService apnsService = apnsServiceFactory.getApnsService();

        ApnsComponent apnsComponent = new ApnsComponent(apnsService);
        camelContext.addComponent("apns", apnsComponent);

        return camelContext;
    }

    /**
     * Création de la route Camel permettant de simuler la production de messages
     * à destination des serveurs APNS.
     */
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from("direct:test").
                setHeader(ApnsConstants.HEADER_TOKENS, constant(FAKE_TOKEN)).
                to("apns:notify");
            }
        };
    }
}

Tester l’intégration d’un composant Camel avec Spring

Les configurations Camel sont souvent déclarées par des fichiers de configuration Spring. C’est pourquoi il est nécessaire de tester l’intégration du composant dans une configuration Spring. Un bon moyen d’automatiser ce type de test est d’utiliser les classes de support JUnit fournies par Spring ( _AbstractJUnit4SpringContextTests_ ).

L’ensemble de la configuration est déclarée dans le fichier SpringApnsConsumerTest-context.xml associé au test unitaire. Les différents beans utilisés par la classe de test sont injectés via les annotations @Autowired et @EndpointInject(uri = “mock:result”).

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:camel="http://camel.apache.org/schema/spring"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

	<bean id="apnsServiceFactory" class="org.apache.camel.component.apns.factory.ApnsServiceFactory">
		<property name="feedbackHost" value="localhost" />
		<property name="feedbackPort" value="7843" />
		<property name="gatewayHost" value="localhost" />
		<property name="gatewayPort" value="7654" />
		<property name="sslContext" ref="sslContext" />
	</bean>

	<!-- Déclaration de l'ApnsService, utilisé par l'ApnsComponent -->
	<bean id="apnsService" factory-bean="apnsServiceFactory" factory-method="getApnsService" />

	<bean id="sslContext" class="org.apache.camel.component.apns.util.FixedCertificates" factory-method="clientContext"/>

	<!-- Déclaration de l'ApnsComponent. Le scheme utilisé pour la création des endpoints -->
	<!-- sera l'Id utilisé pour la création du bean -->
	<bean id="apns" class="org.apache.camel.component.apns.ApnsComponent">
		<property name="apnsService" ref="apnsService" />
	</bean>

	<!-- Déclaration du context Camel, et de la route de test: 'apns-test' -->
	<!-- Les message reçus par le flux feedback seront envoyés vers le endpoint mock:result -->
	<camelcontext id="camel-apns-test" xmlns="http://camel.apache.org/schema/spring">

		<route id="apns-test">
			<from uri="apns:consumer?initialDelay=500&amp;amp;amp;amp;delay=500&amp;amp;amp;amp;timeUnit=MILLISECONDS" />
			<to uri="log:org.apache.camel.component.apns?showAll=true&amp;amp;amp;amp;multiline=true" />
			<to uri="mock:result" />
		</route>

	</camelcontext>

</beans>

Une fois la déclaration du composant Camel effectuée via le fichier de configuration Spring, il ne reste plus qu’à injecter les différents beans configurés dans les propriétés de la classe de test. Le contenu du test en lui-même reste identique, cependant la partie configuration a disparu ce qui rend le test plus lisible. Afin de faire disparaître du test ce qui peut encore en parasiter sa lisibilité, une classe de test parent peut être créée pour contenir les méthodes d’initialisation et d’arrêt du serveur APNS de test.

@ContextConfiguration
public class SpringApnsConsumerTest extends AbstractJUnit4SpringContextTests {

    ApnsServerStub server;

    /**
     * Injection du context Camel déclaré via Spring
     */
    @Autowired
    protected CamelContext camelContext;

    /**
     * Injection du endpoint Camel "mock:result" déclaré via Spring
     */
    @EndpointInject(uri = "mock:result")
    protected MockEndpoint mock;

    public SpringApnsConsumerTest() {
    	super();
    }

    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() throws InterruptedException {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }

    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }

    /**
     * Test du consommateur
     */
    @Test(timeout=5000)
    public void testConsumer() throws Exception {

    	byte[] deviceTokenBytes = ApnsUtils.createRandomDeviceTokenBytes();
        String deviceToken = ApnsUtils.encodeHexToken(deviceTokenBytes);

        mock.expectedMessageCount(1);
        mock.message(0).body().isInstanceOf(InactiveDevice.class);

        byte[] feedBackBytes = ApnsUtils.generateFeedbackBytes(deviceTokenBytes);
        server.toSend.write(feedBackBytes);

        Thread.sleep(1000);

        mock.assertIsSatisfied();

        InactiveDevice inactiveDevice = (InactiveDevice)mock.getExchanges().get(0).getIn().getBody();
        Assert.assertNotNull(inactiveDevice);
        Assert.assertNotNull(inactiveDevice.getDate());
        Assert.assertNotNull(inactiveDevice.getDeviceToken());
        Assert.assertEquals(deviceToken, inactiveDevice.getDeviceToken());
    }

}

Limitations du composant actuel

Dans un soucis de simplicité, le composant présenté est limité fonctionnellement et ne propose qu’un ensemble réduit de fonctionnalités. L’implémentation proposée dans ce billet nous oblige à déclarer les tokens à notifier directement au niveau de la route. Cependant une implémentation plus complète pourrait permettre d’exploiter des en-têtes par exemple pour rendre la sélection de token à notifier plus dynamique.

Heureusement, la richesse du framework Apache Camel nous permet de passer outre cette restriction et d’obtenir l’aspect dynamique souhaité en utilisant le pattern Recipient List, qui permet par exemple l’extraction des URIs de destination depuis un en-tête de message produit au préalable.

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        from("direct:a").recipientList(
        header("recipientListHeader").tokenize(","));
    }
};

Dans cet exemple, l’en-tête recipientListHeader contiendrait les différentes URIs séparées par des virgules.

Utilisation du composant dans un projet

Pour utiliser le composant développé dans cette série d’articles, il suffit de l’importer en tant que dépendance Maven dans votre projet Camel et de déclarer le repository qui permettra de le charger à défaut de l’avoir déjà dans son répository local.

Ce qui donne les lignes suivantes à ajouter dans le pom de votre projet:

• La dépendance Maven:

<dependency>
    <groupid>org.apache.camel</groupid>
    <artifactid>camel-apns</artifactid>
    <version>2.4.0</version>
</dependency>

• Le repository Maven qui met à disposition le composant:

<repositories>
    <repository>
        <id>camel-apns.repo-release</id>
        <url>http://camel-apns.googlecode.com/svn/maven/public/repository/release/</url>
    </repository>
</repositories>

Exemples d’utilisation

Afin de donner une vision synthétique de l’usage de notre composant, voici un condensé de quelques exemples d’utilisation:

• Consommation du flux feedback avec une configuration Java

      from("apns:consumer")
            .to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
            .to("mock:result");

• Envoi de notifications avec une configuration Java

      from("direct:test")
            .setHeader(ApnsConstants.HEADER_TOKENS, constant(FAKE_TOKEN))
            to("apns:notify");

• Envoi d’une notification avec une configuration Spring

<camelcontext id="camel-apns-test" xmlns="http://camel.apache.org/schema/spring">

	<route id="apns-test">
		<from uri="apns:consumer" />
		<to uri="log:org.apache.camel.component.apns?showAll=true&amp;amp;amp;amp;multiline=true" />
		<to uri="mock:result" />
	</route>

</camelcontext>

Conclusion

Nous avons vu dans cet article comment créer et tester un composant Camel qui communique avec les serveurs de notifications d’Apple. Les API du framework ont été pensées pour faciliter le développement de nouveaux composants, et vous permettront d’implémenter et de tester facilement les composants dont vous avez besoin. Vous pouvez consulter le code source du composant camel-apns présenté dans cette série d’article sur sa page Google Code.

Liens utiles

Le site google code du composant ‘camel-apns’ présenté dans le billet:

• http://code.google.com/p/camel-apns

D’autres liens utiles sur le développement de composants Camel:

• Créer des tests unitaires Apache Camel
• Tester un composant Apache Camel

Précédentes parties de l’article:

• Créer un composant Apache Camel de connexion à l’APNS – 1 sur 3
• Créer un composant Apache Camel de connexion à l’APNS – 2 sur 3