florentgarin.org

Il y a quelques jours lors d'un déjeuner avec Jean-Marie Damas (un des organisateurs de l'Agile Tour), nous avons évoqué le framework Eclipse RAP (Rich Ajax Platform).
Ce framework n'est pas vraiment tout nouveau et finalement si discret qu'il n'est pas très connu.
L'idée de RAP est d'être le pendant de RCP (Rich Client Platform) dans le monde Web. Il fournit le même environnement "Workbench" et les applications RAP sont implémentées avec les mêmes APIs SWT et JFace que celles tournant sous RCP.
Cette approche universelle peut séduire mais elle me rappelle un peu trop de nombreuses autres tentatives de grand écart qui se sont soldées pour la plupart par des échecs. JDO (Java Data Objects), par exemple, voulait offrir une API unique de persistance et cela quelque soit le système de stockage sous-jacent (BD, XML, fichiers à plat...).

Si l'on souhaite obtenir le meilleur de la plateforme d'exécution il n'est pas souhaitable de concevoir une application web comme une application lourde, une application de bureau comme une application pour mobile...La liste est longue !

Ca y est, Toulouse a dorénavant son JUG !
Il était anormal qu'une ville avec une telle concentration de sociétés technologiques n'abrite pas de Java User Groups.

Pour ceux qui ne le savent, l'idée des JUG est de réunir les utilisateurs et les développeurs de Java dans un esprit d'échange et de convivialité. Nous organiserons des conférences gratuites et ouvertes à tous où seront faites des présentations techniques.

La première est prévue autour de mars/avril, le temps de trouver des sponsors et de mettre en place la logistique.

N'hésitez pas à vous inscrire sur le site ou à nous contacter pour participer.

A bientôt.

En faisant le ménage sur mon PC, je suis tombé sur cette photo que j'avais prise lors de mon séjour au mois de janvier chez eBay.
La raison de ma venue chez eux était liée à eBox.
Sans pouvoir donner beaucoup de détails pour cause de NDA, eBox est un framework extrêmement ambitieux. Le calendrier initial prévoyait la sortie de la version 1 pour 2008 avec certains modules en open source.
Hélas, l'année s'achève et quand on recherche "ebay ebox" sur google on ne trouve rien de plus récent que 2007 !

J'espère que cela n'est pas le signe d'un deuxième Krach Internet, j'ai rencontré chez eBay des gens passionnants dont les travaux m'ont souvent impressionné et j'aimerais bien en parler !

Comment installer glassfish en tant que service sous linux ?
Contrairement à Windows, installer n'importe quelle application sous forme de service n'est pas très compliqué sous un OS de type Unix.
Le billet suivant explique clairement la démarche à adopter.

Malheureusement, un petit hic survient quand on souhaite faire tourner glassfish sur le port 80.
Sous linux, il est purement et simplement impossible de configurer glassfish sur le port 80 si celui-ci ne tourne pas avec le compte root ce qui est toujours regrettable pour des raisons évidentes de sécurité.

Confronté à ce problème, j'ai tout d'abord envisagé (comme à la grande époque de Tomcat) de positionner un apache écoutant sur le port 80 devant glassfish qui serait lui sur le 8080. Je me suis aussi dit qu'au passage grâce à apache je pourrais faire du "Virtual Hosting" et utiliser les quelques applications php dont nous avons besoin.

Cependant, un tour sur internet, a vite calmé mes ardeurs. Les nombreux commentaires de ce post n'encouragent pas à la confiance.

Finalement, après mûre réflexion, j'ai choisi de laisser glassfish s'exécuter avec le compte root. Hormis cet inconvénient qui je l'espère ne tardera pas à être corrigé, les fonctionnalités natives de "Virtual Hosting" de glassfish, l'architecture modulaire OSGi de la version 3 et le repositionnement de la JVM comme une plateforme multi-langage me font penser que glassfish pourrait bien également concurrencer apache !

Ce message fait suite à mon précédent billet concernant le download et surtout l'upload de fichiers par Web Services SOAP.

Le bug 29 du projet jax-ws a bien été résolu, avec un petit bémol car la correction ne fonctionne qu'avec les Web Services à base de Servlet et non ceux basés sur les EJB Session. Cependant, pour transférer les données binaires MTOM utilise un transfer-coding de type chunked. Il s'agit d'une fonctionnalité d'HTTP 1.1 permettant d'envoyer ou de recevoir une requête HTTP par morceau.

La version 1.1 du protocole HTTP est vieille de plus de 10 ans. Malheureusement, dans de nombreuses organisations, sévissent encore des proxies web ne supportant que la version 1.0 !
Du coup, il n'est plus possible d'appliquer la propriété JAXWSProperties.HTTP_CLIENT_STREAMING_CHUNK_SIZE sur le proxy du client. On se retrouve alors avec le problème initial ; on risque le "out of memory" côté client en téléchargeant sur le serveur (upload) un fichier volumineux.

Enfin, que les utilisateurs de DocDoku se rassurent, par défaut les échanges de fichiers se font par Web Services MTOM et en cas d'environnement réseau hostile (proxy http 1.0) le client bascule automatiquement dans un mode HTTP basique (multipart/form-data).