Récemment, lors d’une intervention sur une application Flex, j’ai été confronté à un problème de migration d’une version de la librairie Spring BlazeDS Integration (passage de la version 1.0.0.RC2 à 1.0.0.M2). Cette librairie permet la configuration de BlazeDS à travers Spring de façon simplifiée. J’ai voulu configurer un appel à un service Java en Remoting.
Afin de déclarer votre service Remote, les lignes suivantes doivent être ajoutées dans votre applicationContext.xml :
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<value>
/*=mySpringManagedMessageBroker
</value>
</property>
</bean>
<!-- Envoie les requêtes au "message broker" -->
<bean class="org.springframework.flex.servlet.MessageBrokerHandlerAdapter"/>
<!-- Le MessageBroker de BlazeDs -->
<bean id="mySpringManagedMessageBroker" class="org.springframework.flex.core.MessageBrokerFactoryBean" />
<!-- Service myService -->
<bean id="myService" class="com.xebia.impl.MyServiceImpl" />
<flex:remoting -destination message-broker="mySpringManagedMessageBroker" destination-id="myServiceDest" ref="myService" />
Ainsi que la référence au fichier xsd : http://www.springframework.org/schema/flex/spring-flex-1.0.xsd
Malheureusement, au démarrage de votre application, vous aurez cette erreur :
org.springframework.beans.factory.xml.XmlBeanDefinitionStoreException: Line 67 in XML document from ServletContext resource [/WEB-INF/classes/applicationContext-service.xml] is invalid;
nested exception is org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'flex:remoting-destination'.
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
Pourtant cela fonctionnait parfaitement avec les versions précédentes de Spring BlazeDS Integration …
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
Google App Engine (GAE) pour Java, sorti récemment, propose une solide offre d’hébergement de serveur d’applications Java/JEE. Cette solution de cloud computing est conçue comme « platform as a service » : Google fournit l’infrastructure complète, ainsi que l’environnement pour héberger l’application. App Engine propose ainsi de nombreux services, dont notamment un système de base de données, appelé datastore (basé sur Google Big Table). La gestion de la persistance est réalisée par l’ORM Datanucleus, qui supporte les implémentations JDO et JPA.
Je vais vous présenter de manière concise le fonctionnement du datastore. De par sa nature, il impose des contraintes fortes, qui nécessitent de revoir sa façon de modéliser les données et de gérer la persistance dans son application.
Lire la suite de cet article »
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
RIA
SOA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
Xebia poursuit son développement et recrute des développeurs, experts techniques et architectes pour accompagner ses clients et intervenir sur ses projets agiles.
Nous recherchons des professionnels, juniors ou seniors, passionnés de technologies, curieux, ayant le goût du partage et l’envie de progresser à la fois dans les domaines techniques et humains.
N’hésitez pas à nous contacter à travers le formulaire de contact ou directement à l’adresse recrutement@xebia.fr.
Vous avez également la possibilité d’échanger librement avec un de nos consultants afin de mieux nous connaitre : Rencontrer un consultant Xebia.
La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.
Actualité éditeurs / SSII
RIA
Le coin de la technique
Evènements de notre communauté en France et à l’étranger
Lire la suite de cet article »
Le Scrum User Group France, organe affilié à la SCRUM ALLIANCE, a mené, pendant deux mois, une enquête nationale, ouverte à tous, par l’intermédiaire de son site (www.frenchsug.org) afin de collecter des données qualitatives et quantitatives sur l’adoption en France des méthodes agiles les plus utilisées par ceux qui ont décidé d’emprunter le chemin de l’agilité.
Pour télécharger les résultats de cette enquête, suivez le lien suivant.
Mettre au grenier la configuration XML et l’API J2EE, voilà le pari que tentent de relever les frameworks orientés composants. Pour atteindre ce but louable : simplifier la vie stressée du développeur et par là même sauver quelques-uns de ses cheveux, le XML est remplacé par du code Java et l’API J2EE est cachée dans les entrailles du framework. Les pages deviennent des objets Java liés à des templates, auxquels sont ajoutés des composants réutilisables (si, si). Les composants sont ni plus ni moins que d’autres objets Java liés à des templates. Les requêtes, quant à elles, deviennent des événements traités par les pages et les composants.
Voilà pour le principe de cette approche qui semble avoir de beaux jours devant elle. Emergence naturelle ou stratégie voulue, la fondation Apache, jamais avare de solutions, nous propose deux frameworks composants : Tapestry 5 et Wicket. Alors comment choisir ? Le mieux est encore de se faire sa propre idée en les testant tous les deux. Nous sommes bien d’accord, rien ne remplacera jamais l’efficacité du prototypage. Cela n’empêche pourtant pas de faire une pré-sélection basée sur quelques points de comparaisons stratégiques. Voici donc un article pour vous aider à faire le meilleur choix ; à savoir le choix qui répondra le mieux aux besoins et à l’environnement de votre projet.
Bien qu’adoptant tous deux la programmation web orientée composant, les deux projets sont imprégnés d’une philosophie et d’un objectif différents. Les buts principaux de Wicket sont :
- Pages et composant statefull
- Programmation à la Swing
- Séparation stricte entre code et template
Pour Tapestry 5, les objectifs sont différents :
- Optimiser l’utilisation CPU et mémoire
- Simplifier la création de composants
Attention ! Ce sont là les objectifs sur lesquels les deux projets sont focalisés. Ce qui ne signifie pas qu’ils s’y intéressent exclusivement. Wicket supporte bien les composants sans état, ce n’est juste pas son but principal. De même que Tapestry supporte le développement web entièrement en objet Java.
Ils affichent, aussi, des buts communs, comme d’être orientés Pojo et d’éliminer la configuration XML avec le pattern Convention Over Configuration.
Lire la suite de cet article »
Complet
Twitter
