Enjoy.

Vite fait :

affiche la valeur de l’attribut attributeName de l’objet myObject.

affiche ce que renvoie la fonction functionName() de myObject.

A quoi ca sert ?

L’introspection est courante en Java lorsque l’on travaille sur les Annotations. En Groovy, c’est la base du metaprogramming et autre ‘magie’ du langage.

En Javascript, je l’utilise surtout pour créer des composants ExtJs :

La machinerie interne de mon SimpleCombo utilise assez simplement l’introspection et l’on peut déclarer ‘à droite’ l’attribut sur lequel on travail. Le combo affichera l’attribut name et le formulaire enverra la valeur id. Si displayField n’est pas renseigné, on peut alors exécuter la fonction toString().

A chaque fois que vous écrivez du code Java fonctionnant à la fois côté serveur et client, il faut garder en tête de :

– GWT utilise directement les composants du navigateur : il utilise le DOM interne, ainsi que l’objet XmlHttpRequest- et donc ne connait ni Sax, ni JDOM, si le java.net.HttpClient
– Ne pas utiliser de fonctions System : il n’y a pas de compatibilité entre la JVM et le moteur du navigateur. java.util.Locale est incompatible avec GWT car est capable de lire une Locale par défaut dans le System de la JVM
– Ne pas lire un fichier : il est très malheureusement impossible d’utiliser les ResourceBundle pour internationaliser son code.
– Ne pas se mêler des Charset : le fonctionnement est trop différent entre la JVM et le navigateur. Je ne suis pas spécialiste, mais concrètement, les fonctions de type public byte[] getBytes(« UTF-8″) ne fonctionneront pas. Cela rend les fonctions de types MD5 et base64 sont pour l’instant incompatibles.
– Vérifier la liste des fonctions émulées : une fonction assez simple comme Class.getSimpleName() n’est pas émulée.

Alors est-il possible d’écrire une bibliothèque Java utilisable – et utile – côté client et serveur ? Oui, vous y arriverez en y passant suffisamment de temps et à la simple condition de maîtriser le concept de l’interface. Vous pouvez aussi attendre Octobre et la sortie de Robusta Web Library qui vous facilitera grandement la tâche.

• Aucune configuration du serveur ni de la base de donnée : on dépose son application dans un conteneur.
• Il n’y a pas à choisir dans une gamme de serveurs : les requêtes seront exécutées par Google, et on sait qu’ils le font bien
• La facturation est faite selon les coûts réels : si votre application fait un bide, vous ne payez rien
• L’application est développée en un seul langage : Python, ou Java depuis Mars

Cette différentiation colle vraiment à l’innovation. Un bon programmeur Java avec une idée peu créer son application sans perdre de temps à configurer linux+apache+ssl ni faire un prévisionnel des capacités de serveur. Avec Edupassion.com, je sais de quoi je parle. Et si personne ne se connecte, il n’y a pas de coût de serveur inutile, et là aussi je sais… euh passons.

Malheureusement, concrètement, App Engine en Java ne marche pas.

Il est très simple de créer une application HTML, avec Ajax et même GWT, puis de l’uploader. C’est ce que j’ai fait pour le site de mon entreprise, Robusta Web. Si le site en fonctionne pas, essayez… trois minutes plus tard ! D’après le log, à cause d’une jsp déclanchant com.google.apphosting.api.DeadlineExceededException et java.security.PrivilegedActionException. Il semble que la security passe ou bloque de temps à autre. Etonnnant !

J’ai tout de suite essayé d’installer JAX-RS avec Jersey, mais non, pas possible, le container refuse. On propose une version adaptée, qui marche un peu, mais bloque aléatoirement l’accès au site – cette fois-ci avec une vraie exception. Normal, c’est du bidouillage.

Plus gênant est l’utilisation des JSP et son mapping. http://www.robustaweb.com/myjax/bond/ fonctionne, mais pas http://www.robustaweb.com/myjax/bond . Différence subtile, pas contraire aux spécifications assez muettes, mais juste incroyable.

Mais le grand problème est l’accès aux données. D’une part à cause des couches successives JPA->JDO->Implementation Google->DataNucleus->BigTable, comme l’avait déjà fait remarqué Bruno Marchesson. Pour faire court, quoi que vous tentiez, cela échouera :).

J’ai quand même réussi à « persister » quelques objets, et même à les lire. Mais s’il existe peut-être des logiciels permettant de visualiser ces données, aucun n’est clairement référencé. Alors qu’avec une table MySql, vous n’avez aucun problème à savoir ce que vos tests ont générés.

Pour l’instant App Engine me parait donc inutilisable dès qu’il s’agit de sauver des données. Il semble dangereux d’y mettre un simple site avec des JSP. Quelques pages HTML peut-être….

Mais n’oublions pas que App Engine est en Early Access, et je suis plutôt optimiste : Google developpe très bien ses produits quand ils trouvent un public en face. J’y retournerai dans six mois.

Depuis un peu plus d’un an, l’architecture d’Edupassion est passée RESTful et j’ai décidé d’épurer la biblitohèque afin de fournir un ensemble d’outils légers et cohérents facilitant les usages fréquents lors d’un processus REST. Simplicité et Productivités sont (en principe ) les maîtres mots.

Le premier tutoriel est en cours d’écriture, et RWT est téléchargeable dans une version qui évoluera encore un peu, l’essentiel du travail restant étant d’écrire une documentation convenable.

Vous pouvez toutefois vous amuser avec :

• VerySimpleXml pour SAX (RwtSax) ou JDOM (RwtJdom)
• Les classes utilitaires Couple et CoupleList
• Des Clients Http simplifié et spécialisés, à partir du Client Sun (RwtSunClient, idéal pour les applets) ou du client Apache (RwtApacheClient)
• Un ResourceController pour JAX-RS (JaxRsResourceController)

La version 0.9 stable et quasi définitive sera disponible au plus tard la semaine prochaine. En espérant des commentaires et peut-être quelques add-on de la communauté pour une version 1.0 en Septembre.

J’avais déjà fait une vidéo sur la création d’un pool de connexion MySQL sur Glassfish. Malheureusement, lors de la pratique en test réel avec une application web et des alpha-testeurs, plus rien ne fonctionnait au bout de quelques heures : « Impossible to resize Pool » x 500 dans mes logs.

Créer plus de Connexions possibles n’a pas servi à grand chose (j’ai testé avec 256 au lieu de 16 :)) ). Par contre j’ai voulu pingé le pool grâce à l’interface de Glassfish. Lorsqu’aucune application n’est déployé, le pool ne ping pas puisque le .jar de Mysql n’est pas installé par défaut.

J’ai donc :

• Copié mon Mysql Connector/J dans /usr/share/glassfish/lib
• Précisé le .jar dans le Classpath de la JVM du serveur
• Ajouté tant qu’à faire de la mémoire : c’est un serveur java !

D’une part je ping, et de plus je peux maintenant bombarder mon serveur de requêtes. J’en déduis peut-être à tort qu’utiliser le mysql.jar dans le /lib de son .war ne tient pas très bien la route.

Le serveur encaisse bien son millier de requêtes, et pour l’instant, je n’ai pas d’avertissements d’OVH .

Voici deux vidéos-tutoriels permettant de fabriquer des composants Javabeans de façon simple, rapide et avec du code propre grâce à Netbeans

– I) Beans Binding : Synchroniser la valeurs d’une propriété avec celle d’un formulaire
– II) Programmation par Events : Réduire les combinaisons if/else avec une programmation modulaire, pilotée par les Events customizés.

Deux vidéos devraient arriver après les fêtes. Les articles pour Dev.com…. en avril

Coté Client, les Javabeans peuvent être utilisé par Netbeans pour créer des composants structurés pouvant interagir avec d’autres composants ou votre JPanel via des Events. Concrètement, c’est un élément supplémentaire de votre Palette, comme un JComboBox ou une JTable.

Il est possible de définir soi-même les Events agissant sur votre objet. Ainsi, au lieu de gérer 25 composants Swings standards (JButton, JLabel, JCombo) sur un seul Panel, vous aurez 5 Javabeans avec 5 chacun composants Swing interagissants avec des Events.

Le Javabeans va modifier son comportement selon les données entrantes (myJavabean.setTeacher() ) ou les Events. J’ai ainsi considérablement limité le nombre de if/else, mais en augmentant par contre le nombre de Classes. Selon l’auteur de XP, il faut limiter le nombre de Classes, mais ici je considère un package comme étant une Classe.

Au final, il y a beaucoup moins de bugs et j’ai refait en une semaine ce qui m’avait pris – je débutais – plusieurs mois !

Cependant certaines requêtes seront très fréquemment utilisées par les utilisateurs : l’accès aux tokens d’authentification, et l’accès aux notes pour les profs et élèves. Il me parait donc logique de faire du JDBC pour optimiser ces deux-trois cas d’utilisation. Mais JDBC est-il vraiment plus rapide ? JPA vs JDBC : voici ce que j’ai trouvé sur java.net :

L’architecture est plus importante que la technologie :

[QUOTE]
The performance is completely
dependent on what you want to achieve and what actual providers you are
using. You should decide for a technology on a design or architecture
level. If you really want to decide on a performance level, you have not
understood what both are good for. Both are neither competitive, nor
comparable.
[/QUOTE]

A première vue, cela ne m’apporte rien. Un visiteur passe donc apporter la contradiction : puisque JPA est basé sur JDBC, un excellent programmeur serait capable de faire toujours mieux avec JDBC qu’avec JPA. Encore faudrait-il qu’un bon développeur existe – cela me rappelle Lex&Yacc …

[QUOTE]
With JPA vs JDBC, this is exactly the same. JDBC is the building block upon which JPA is built. JPA (as a result of standing on the
shoulders of JDBC) can never be faster than _properly tuned_ raw JDBC.
However, the JDBC code that most developers will write is going to be
slower than JPA 99% of the time…
[/QUOTE]

La réponse qui tue : JPA et JDBC n’ont pas le cache au même endroit (?!).

[QUOTE]
the JPA cache is on the client side, while the JDBC / DBMS cache is on the server side. Assuming a JDBC-based JPA implementation, you will benefit from this double buffering (if you have luck, the object is in the client side JPA cache; if you have not so good luck, it is found in the server side JDBC / DBMS cache; if you have bad luck, you must go down to the hard disc). If you do JDBC on the client side, then there is no client cache (unless your particular driver vendor implemented one directly in the client side driver). So, a JPA query will return client side cached objects, while a JDBC query must forward the server side cached data over the LAN. In sum, you have far more LAN transport with JDBC than with JPA. Unless you have client and server on the same machine, what is untypical in Client-/Server computing
[/QUOTE]

Pour ce que j’arrive à traduire et surtout comprendre, plus la quantité de données échangées entre JPA/JDBC et le serveur MySQL est importante à chaque requête, plus il est préférable de s’orienter vers JPA. Pour récupérer un token, ce serait JDBC, alors que pour récupérer un ensemble de notes dispersées entre plusieurs classes, groupes et périodes, ce serait JPA.

Ce dernier point me fait dire que si je veux faire du benchmarking, il n’aurait pas grand sens. A court terme, ma base de données est évidemment sur le même serveur, mais si j’ai un peu de succès, ca ne sera plus le cas.

• Code Browser : HTML reçu par la front view, Ajax vers le web service
• Front view (Module Edupassion) : Distribution du HTML, redirection au Web Service
• Web Service (module wsedupassion) : http -> JSP -> Javabean -> validation -> accès données -> analyse -> résultat xml
• Code métier (module e-library) : contient les classes School, Teacher, Student, Work, etc.
• Accès données (module JPA+Crud) : Les classes Entities sont générées par Netbeans 6.5. Le Crud convertit ces entities en classes métiers de e-library.
• La base de donnée : On y accède soit par les entities, soit par des requêtes JPA, et parfois par des requêtes jdbc.

JPA
La seule originalité est la séparation franche entre les Entities issues de la Bdd et les classes métiers qui en sont presque des clones. Mais pour moi il est hors de question de rajouter la moindre ligne au milieu d’un code remplit d’annotation et de requêtes à mon avis difficile à maintenir.

J’apprécie cependant énormément de faire un Crud via ces Entities plutôt que par JDBC. La maintenance est plus simple, puisque, par exemple, en renommant une colonne de ma BDD, Netbeans génèrera des classes différentes et fera remarquer une erreur dans le code de mon CRUD. Cela est impossible avec du JDBC pur.

REST
L’accès aux web service se fait par REST, via des requêtes GET, POST, PUT et DELETE. Il a fallut pour cela modifier le fichier de Prototype, ce qui n’est pas très difficile. Un Web Service RESTFul permet principalement une montée en charge du projet sereine, sans modifier le code source.