All posts in Java

Upload et download de fichiers avec un web service

By Florent Garin / 18 novembre 2007 / 10 Commentaires

Comment faire pour « uploader » et « downloader » un fichier vers et depuis un web service ?
Très simple me diriez-vous et depuis longtemps. Il suffit d’utiliser SAAJ (SOAP with Attachments API for Java) ou encore mieux MTOM (Message Transmission Optimization Mechanism) pour bénéficier de l’assurance d’une compatibilité .Net/Java optimale.
En théorie cela semble simple mais quand on passe à la pratique, dans le contexte d’une application réelle, les choses se compliquent bigrement, en tout cas en ce qui concerne l’implémentation de JAXWS.
La plus grosse lacune de JAXWS au niveau MTOM est son incapacité à transmettre les données binaires sous forme de flux de bout en bout. Comme expliqué ici il est bien possible d’indiquer au client d’utiliser le mode « streaming » mais côté serveur rien à faire, l’ensemble des octets constituant le fichier est monté en mémoire.
Même côté client, JAXWS mériterait quelques améliorations. En effet il n’est pas possible de superviser la progression du transfert, de plus le mode « streaming » opère en appelant HttpURLConnection.setChunkedStreamingMode sur la connexion sous-jacente ce qui pose des problèmes car de nombreux serveurs web ou proxy ne supportent pas ce mode. Il serait intéressant que JAXWS calcule la taille du contenu à poster et invoque plutôt la méthode HttpURLConnection.setFixedLengthStreamingMode.

Conclusion de tout cela, pour uploader un fichier en http rien ne vaut d’utiliser directement HttpURLConnection et d’implémenter le basique et standard upload multipart/form-data.

JAXB 2.1 avec Java 6

By Florent Garin / 3 octobre 2007 / Commentaires fermés sur JAXB 2.1 avec Java 6

Le choix d’inclure (précipitamment ?) JAXB au jdk 1.6 a des conséquences fâcheuses. En effet, la version de l’API intégrée au jdk est la 2.0, et très souvent il est indispensable de passer à la 2.1 pour bénéficier de fonctionnalités comme par exemple l’annotation XmlSeeAlso.
Pas de problème me diriez-vous, il suffit de rajouter -Djava.endorsed.dirs=jaxb-api.jar à la ligne de commande de java pour « patcher » le jdk.
Malheureusement, si votre application est distribuée au travers de Java Web Start, le mécanisme de classes « endorsed » ne fonctionne pas.
Pour s’en sortir une seule solution faire des acrobaties avec les ClassLoaders. Ce billet explique cela en détail. Dans le cadre d’une application swing, il faudra bien penser à appeler la méthode setContextClassLoader également sur le thread gérant les événements système comme ceci :
EventQueue eq = Toolkit.getDefaultToolkit().getSystemEventQueue();
eq.invokeAndWait(new Runnable() {


public void run() {


Thread.currentThread().setContextClassLoader(modifiedClassLoader);

}


});

C’est du sport mais ça marche !

web services avec JAX-WS

By Florent Garin / 17 juillet 2007 / 5 Commentaires

Initialement le client (java web start) DocDoku communiquait au serveur (composants ejb) à l’aide du protocole corba IIOP.
Malheureusement, à tort ou à raison, les proxies http sont souvent le passage obligé pour accéder à internet dans de nombreuses sociétés.
Nous avons donc décidé de passer aux web services. Aujourd’hui cette migration est terminée mais je dois avouer que ce fut plus compliqué que prévu. Voici un bref retour d’expérience :

Au niveau sécurité, les options sont nombreuses, nous avons néanmoins opté, par prudence, pour la simplicité : authentification basic sur du SSL.
Ce poste explique ceci en détails.

Ensuite, la grande difficulté a été d’utiliser nos POJOs sur le client et le serveur sans passer par une couche d’objets intermédiaires mappant le wsdl.
Etrangement, aucun tutorial de Sun n’explique clairement cela et les assistants de netbeans génèrent invariablement cette couche d’objets (avec la commande wsimport) même si le webservice a été créé à partir d’une interface SEI (Service Endpoint Interface).
Sous les conseils d’Alexis, j’ai filé un bug chez netbeans.
Enfin, la solution est la suivante, il faut donc définir une interface pour l’EJB avec endpoint webservice et non simplement annoter les méthodes avec @WebMethod.
Ensuite, importer les classes produites par wsgen également sur le client.
Enfin, récupérer le web service Port par javax.xml.ws.Service.getPort(Class<T> serviceEndpointInterface).

JSR-170 (Java Content Repository)

By Florent Garin / 16 mai 2007 / 3 Commentaires

La JSR-170 (ou JCR) vise à définir une API standard pour accéder aux « content repositories ». Tous dépôts conformes à cette spec présentent une vue hiérarchique des données et méta-données, offrent des services de versioning, d’import-export XML, ainsi qu’une gestion d’évènement permettant d’être notifié en temps réel des modifications. Les JCR sont également interrogeables au travers d’XPath.
Certains parlent de la JSR-170 comme du jdbc des CMS (Content Management System).
La question est donc de savoir si les JCR arriveront à s’imposer comme briques de bases de tous CMS qui se respectent. La réponse n’est pas évidente.
La JSR-170 est d’une manière ou d’une autre en concurrence avec JPA (Java Persistence API) ou plus généralement avec les ORM. La talon d’achille des JCR est, pour l’instant, l’absence d’outil de mapping Objet/JCR. Il existe bien un embryon de projet mais rien de comparable à Hibernate ou Toplink. Du coup, les gains de productivité dus aux services supplémentaires disponibles pourraient être perdus à développer le mapping objet.
Cependant, les choses pourraient changer assez rapidement, et des outils autour des JCR pourraient apparaître.
Enfin, on peut noter que la JSR-283 est sur les rails, elle corrige certains défauts de sa grande sœur ; par exemple, elle rajoute un type de node spécifique pour les metadata ce qui manque cruellement à la JSR-170.

Problème d’accents dans les applications web

By Florent Garin / 20 février 2007 / 8 Commentaires

La gestion des accents dans les applications web n’est toujours pas, quelque chose de simple qui marche sans qu’on s’en préoccupe !

Quand le navigateur soumet un formulaire, il poste les valeurs des champs en utilisant le même encodage que celui de la page html d’origine.
Dans une jsp, pour spécifier au moteur de servlet l’encodage du flux de la réponse http et donc de la page html générée, nous avons recours à la directive @page comme ceci :

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

Renseigner l’attribut contentType a deux effets ; premièrement d’encoder la réponse dans le format choisi, deuxièmement de l’indiquer au client, par le biais d’une variable dans l’entête http.
Il est cependant intéressant de mentionner cet encodage directement dans la page html. Ainsi, elle pourrait être parsée à nouveau correctement ; par exemple ré-affichée après avoir été sauvegardée sur le disque. Il est donc plus prudent d’ajouter la balise suivante entre les tags head :

<meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>

Enfin, nous pouvons remarquer que la directive @page support également un attribut « pageEncoding ». Cet attribut précise simplement l’encodage de la page jsp elle même. Cette information sert au moment de la compilation de la jsp pour produire la servlet correspondante. Cette valeur dépend de l’IDE, NetBeans (dans sa configuration initiale) sauvegarde les fichiers en utilisant l’encodage par défaut de l’OS : CP-1252 pour Windows et UTF-8 pour linux.

Côté serveur, il faut décoder les paramètres de la requête http avec le même encodage que celui qui a servi à la transmission du formulaire.
Mais quel est celui utilisé quand on appelle HttpServletRequest.getParameter(name) ?
En théorie, à l’instar de ce que fait le serveur dans sa réponse, le navigateur est censé communiquer au serveur, dans l’entête http, l’encodage employé.
Malheureusement, dans la pratique ni Internet Explorer ni Firefox ne le fait. Pour s’en convaincre il suffit d’appeller HttpServletRequest.getCharacterEncoding() et constater que la méthode retourne null.
La conséquence de cela est que si l’object HttpServletRequest ne connait pas l’encodage dont s’est servi le client, il en utilisera un par défaut. Ce paramétrage est propre au serveur d’application, Glassfish par exemple, utilise l’ISO-8859-1. Il est évidemment possible de le changer.
Il est aussi possible de modifier le « CharacterEncoding » programmatiquement grâce à la méthode setCharacterEncoding(value). Si l’application est développée à l’aide d’un framework web (JSF, struts…), il faudra définir un HttpServletFilter pour le faire avant que les couches du framework n’accèdent à la requête.

NSIS installeur avec Java Web Start

By Florent Garin / 6 janvier 2007 / 3 Commentaires

Le client riche DocDoku est une application déployée à l’aide de Java WebStart. Cette technologie nous donne entière satisfaction et nos utilisateurs bénéficient ainsi du système de mise à jour automatique. Cependant, JWS a le léger inconvénient de nécessiter un environnement Java déjà installé.
Nous avons donc créé un setup.exe, avec NSIS. NSIS est un installeur open source uniquement pour Windows. Son utilisation à base de scripts sans assistant ni même interface graphique peut sembler un peu rugueuse mais on finit par s’y faire et apprécier la souplesse que cela procure.
Notre installeur devait être capable de :

  1. vérifier dans le registre la présence d’une JVM 1.5
  2. procéder à son téléchargement et son installation si besoin
  3. installer l’application DocDoku tout en maintenant le « lien » Java Web Start pour conserver la fonctionnalité de maj auto.

Voici notre script NSIS:


; Client Installer

;--------------

Name "DocDoku Client"
Caption "DocDoku Client Installer"
OutFile "docdoku.exe"

!define JRE_VERSION "1.5"
!define JRE_URL "http://dlc.sun.com/jdk/jre-1_5_0_01-windows-i586-p.exe"

Section

Call DetectJRE
ReadRegStr $1 HKLM "SOFTWARE\JavaSoft\Java Runtime Environment" "CurrentVersion"
ReadRegStr $0 HKLM "SOFTWARE\JavaSoft\Java Runtime Environment\$1" "JavaHome"
ExecWait "$0\bin\javaws.exe -import -silent -shortcut http://www.docdoku.com/apps/docdoku_client.jnlp" $4

StrCmp $4 0 done
MessageBox MB_OK "Failed: your Java Runtime Environment is corrupted, please uninstall it and retry"
done:

SectionEnd

Function GetJRE

MessageBox MB_OK "DocDoku uses Java 1.5, it will now \
be downloaded and installed"
StrCpy $3 "$TEMP\Java Runtime Environment.exe"
nsisdl::download /TIMEOUT=30000 ${JRE_URL} $3
Pop $R0 ;Get the return value
StrCmp $R0 "success" +3
MessageBox MB_OK "Download failed: $R0"
Quit

ExecWait $3
Delete $3
FunctionEnd

Function DetectJRE
ReadRegStr $2 HKLM "SOFTWARE\JavaSoft\Java Runtime Environment" \
"CurrentVersion"
StrCmp $2 "" download
StrCpy $8 ${JRE_VERSION} 1
StrCpy $9 $2 1
IntCmp $9 $8 0 download done
StrCpy $8 ${JRE_VERSION} 1 2
StrCpy $9 $2 1 2
IntCmp $9 $8 done download done

download:

Call GetJRE

done:

FunctionEnd

Seul petit défaut, nous ne disposons pas d’URL permettant de télécharger (sans aucune interaction utilisateur) le JRE 1.6 ; mais seulement le 1.5.

EJB et les enums 1.5

By Florent Garin / 30 octobre 2006 / 2 Commentaires

Je suis en pleine refonte de l’application collaborative en ligne DocDoku.
Je migre d’une architecture customisée fondée sur de simples services RMI de base, tournant dans la même JVM que le moteur de servlet (tomcat), vers une architecture standard JEE 1.5 supportée notamment par les EJB 3 (glassfish).
Durant ce portage, je suis tombé sur un bug assez vicieux ; l’implémentation actuelle du protocole IIOP (jdk 1.5) ne sérialise pas correctement les type « enum ». En conséquence, une comparaison de deux enumérations dont l’une a été envoyée par le client, d’apparence identique, échoue lamentablement !
Seule alternative, comparer leur nom…

Open Source Java

By Florent Garin / 18 mai 2006 / 3 Commentaires

Ca y est, Sun a annoncé officiellement, à l’occasion de la conférence JavaOne, son intention de passer Java sous licence open source !
C’est une grande nouvelle, cela devrait permettre, entre autres, aux distributions linux d’intégrer une JVM Java en standard, de corriger enfin les bugs de Swing, de faciliter le packaging des applications java en y encapsulant un JRE custom…

Je suis curieux de voir l’impacte à long terme de cette nouvelle licence ; « linux + java » va t-il devenir le couple gagnant ? java va t-il enfin décoller sur le client ?

Authentification par formulaire en jsp

By Florent Garin / 23 février 2006 / 7 Commentaires

La spec jsp prévoit la possibilité de définir une page html pour l’authentification en lieu et place de la popup de logging du navigateur. Pour cela, il suffit de concevoir un formulaire comme ceci :

form method="post" action="j_security">
<input type="text" name="j_username"/>
<input type="password" name="j_password"/>
</form>

Parfait, il est donc possible de personnaliser la fenêtre de logging et de la fondre dans le design général de l’application ; tout en bénéficiant d’une authentification déclarative assurée par le « container » cad le moteur de servlet.

Seulement voilà :

Comment permettre une authentification active des utilisateurs (on se logue volontairement ; on n’est pas contraint de montrer patte blanche seulement après avoir tenté d’accéder à une zone sécurisée) ?
Comment implementer une option « remember me » (l’application dispense l’utilisateur de ressaisir son login et mot de passe systématiquement) ?

C’est impossible !

Si l’on tient à ces fonctionnalités, il nous faut alors laisser tomber l’authentification par container et développer une authentification « custom » à base de ServletFilter et renoncer par la même occasion aux methodes HttpServletRequest.getRemoteUser et HttpServletRequest.isUserInRole.
Tout ceci ne facilitera pas une éventuelle intégration SSO, mais bon, quand le standard est mauvais ou incomplet…

Java autoupdate

By Florent Garin / 6 février 2006 / 3 Commentaires

Java bénéficie depuis le JRE (Java Runtime Environment) 1.5 d’une fonctionnalité de mis à jour automatique.
Ainsi à interval régulier (par défaut une fois par mois) le système téléchargera et installera la toute dernière version du JRE si nécessaire.
Seul « petit » hic, la version précédente n’est pas désinstallée ! C’est à l’utilisateur de le faire, s’il y pense bien sûr.
Sachant que la nouvelle politique de Sun est de délivrer ses correctifs plus fréquemment, on peut se retrouver avec 4 ou 5 JRE de près de 70Mo sur son poste alors que l’on pensait télécharger de simples patches !
Ce choix de déploiement (excessivement ?) défensif peut se comprendre en entreprise, mais si Sun veut imposer Java sur le client face à des concurrents tel que Flash il devra sans doute revoir sa copie.

RMI et les ports

By Florent Garin / 6 octobre 2005 / 2 Commentaires

Classiquement, pour développer un serveur RMI, nous devons :

  • Définir une interface avec l’ensemble des méthodes « remotes » (cette interface étendra java.rmi.Remote).
  • Implémenter cette interface dans une class étendant java.rmi.server.UnicastRemoteObject.
  • Enregistrer le serveur auprès d’un registre RMI (il convient d’avoir précédemment lancé la commande rmiregistry).

Au niveau du code côté client, nous devons récupérer une référence de cet objet (son stub) à l’aide de la méthode Naming.lookup(name) qui interroge le service rmiregistry.

Dans le contexte d’un réseau local, cela fonctionne sans que l’on ait vraiment besoin de se préoccuper des ports de communication. Maintenant, si l’on souhaite offrir l’accès à notre serveur aux utilisateurs se trouvant en dehors du LAN, nous devons maîtriser les ports TCP/IP ouverts par notre application pour configurer notre pare-feux et les redirections NAT.

Grâce à la commande netstat nous constatons que rmiregistry écoute le port 1099 et que notre processus java un autre port qui varie à chaque lancement. Le port 1099 est le port par défaut du registre RMI. Il est toutefois possible d’en spécifier un autre en paramètre de la commande rmiregistry. Le second port correspond au port de notre propre service. Toujours grâce à la commande netstat nous remarquons que notre client se connecte une première fois au rmiregistry (sur le port 1099) puis ne dialogue plus qu’à notre application au travers du second port.

Tout ceci ne nous arrange pas, comment définir des règles sur le « router/firewall » si le second port change à chaque redémarrage ?
Un petit tour dans la javadoc nous apprend que le constructeur de la class UnicastRemoteObject admet pour paramètre le port d’écoute. Parfait, nous ajoutons donc super(port) dans le constructeur de notre serveur.

Cependant, nous ne pouvons choisir 1099 car ce port est déjà utilisé par le processus rmiregistry. Heureusement, il y a une solution, nous n’exécuterons plus la commande rmiregistry ; nous créerons directement le registre RMI dans la JVM de notre serveur au moyen de l’instruction LocateRegistry.createRegistry(pPort).

Ainsi nous arrivons à nos fins, notre application ne monopolise qu’un unique port connu et paramétrable.

Harmony

By Florent Garin / 30 août 2005 / 5 Commentaires

Voilà quelques mois, le projet harmony a officiellement démarré à la fondation Apache.
Ce projet a pour but d’offrir une implémentation open source des spécifications de « Java 2 Platform, Standard Edition ».
Concrètement, il s’agit de développer l’environnement d’exécution, les APIs, le compilateur et l’ensemble des outils standards.
Certains pensent que ce projet est sans intérêt car l’implémentation de Sun, bien que sous licence propriétaire, est gratuite.
Je ne pense pas comme cela. Je vois trois avantages majeurs à bénéficier d’un environnement java open source :

  • Plus de plateformes supportées

Java est un langage multi-plateforme. Cependant Sun ne fournit « que » trois verions de son dernier JRE (Java Runtime Environment) 1.5 ; une pour MS Windows (x86 et AMD64), une pour Solaris (SPARC, x86 et AMD64) et une pour linux (x86 et AMD64).
Apple met aussi à disposition de ses clients la dernière JVM pour MacOS (processeur PPC).
Mais que faire si l’on souhaite installer une JVM sur un serveur linux PPC ? Se tourner vers la distribution d’IBM et se contenter de la version 1.4.2.
Pire encore, si l’on utilise l’OS freeBSD il faut se satisfaire d’une version 1.3 qui n’a pas passé les tests de conformité.
Que dire des nouvelles consoles de jeux ; Xbox360, playstation3 et nintendo révolution, aucune d’entre elles ne peut, pour l’instant, faire tourner java.
Le slogan « Write once run everywhere » de java n’est aujourd’hui que partiellement vrai. Le projet Harmony s’il aboutit pourrait changer la donne.

  • Accélérer la correction des bugs

Certaines anomalies concernant l’API Swing (interface graphique) sont enregistrés dans la base de bugs de Sun depuis plus de 7 ans…
Avec une JVM open source, la communauté des développeurs ne serait plus dépendante d’un éditeur et les « bug fix » se feraient certainement plus rapidement.

  • Distribution du JRE plus aisée

Les JRE de Sun bien qu’étant librement téléchargeable n’en demeurent pas moins propriétaire et leur distribution soumise à de nombreuses contraintes. Il n’est pas possible par exemple de livrer une application java avec un JRE allégé des classes non utilisées. Il n’est pas non plus possible d’intégrer le JRE dans les distribs linux (programmes sous licence GPL et propriétaire ne peuvent cohabiter sur le même media).
Interdit aussi de repackager le JRE sous forme de package debian ou rpm et profiter ainsi des mis à jour en ligne du système (l’équivalent, en mieux ;=), du Windows update).
Une fois de plus, un projet comme harmony lèverait ces limitations.

Non-blocking I/O

By Florent Garin / 18 juillet 2005 / 4 Commentaires

« New I/O » is a feature appeared with jdk 1.4, implemented in package java.nio.channels.

This feature allows to define multiplexed Non-blocking I/O operations. Thus, on the server side, it’s not required to spawn a new thread each time a client connects. It’s the responsibility of the application to create a working thread.

Below, a simple example extracted from the NetCopyPaste program in start() method of org.florentgarin.netcopypaste.network.SocketListener class. It’s probably overkill but NetCopyPaste has been voluntarily written using all the latest technologies.

Selector selector = Selector.open();

//we only register read operation
_channel.register(selector, SelectionKey.OP_READ);

//selector.select() method blocks until a registered operation occurs.
//Thus, it's a infinite loop
while (selector.select() > 0 ) {

Set<SelectionKey> readyKeys = selector.selectedKeys();
Iterator<SelectionKey> iti = readyKeys.iterator();

while (iti.hasNext()) {

SelectionKey key = iti.next();
iti.remove();
if (key.isReadable()) {

//we can have created a thread to do the job but in our case
//there's not so much to do, so we have kept our code simple.
MessageEvent messageEvent = readMessage(key);
fireMessage(messageEvent);

}


}


}

Most application servers such as tomcat has been rewritten to take advantage of the nio packages. If your application has some performance or memory usage issues, you must consider refactoring your code.

Java 1.5.0_02

By Florent Garin / 17 mars 2005 / 4 Commentaires

Sun vient de rendre disponible la deuxième mise à jour de la JVM 1.5.0. Cette mise à jour mineure certes, possède néanmoins selon moi un intérêt certain car elle corrige le bug non critique mais très irritant des fonts sous MS Windows. En effet, depuis la version 1.4.2, la police par défaut sous l’OS de Microsoft était mal rendue à l’écran notamment sur les caractères ‘C’,’x’ ou ‘8’. Cela n’était vraiment pas du plus bel effet ! Il semblerait que Sun commence à comprendre l’importance de ces « détails » pour l’image de Java auprès du public ou des décideurs.