
J’ai mis en ligne hier soir une nouvelle page dans la section how to, présentant la configuration d’un active directory authenticator pour weblogic 8.1.
En espérant que ceci puisse aider.

J’ai mis en ligne hier soir une nouvelle page dans la section how to, présentant la configuration d’un active directory authenticator pour weblogic 8.1.
En espérant que ceci puisse aider.
Lu sur Silicon.fr :
Les « Protocol Buffers » sont distribués sous licence Apache 2.0 par Google. Ils permettent de structurer l’information qui circule entre des serveurs ou des applications. La compagnie voit en cette technologie une alternative au XML, qu’elle juge inadapté pour un usage à grande échelle.
Après avoir parcouru la doc de ce nouveau format d’échange, voici ce qu’on peut en dire :
Protocol buffer est beaucoup moins verbeux qu’XML, les messages ainsi échangés seront de ce fait beaucoup plus légers.
Par exemple une personne en XML serait décrite de la façon suivante :
<person>
<name>John Doe</name>
<email>jdoe@example.com</email>
</person>
Alors qu’en protocol buffer on aurait :
person {
name: “John Doe”
email: “jdoe@example.com”
}
La définition du format se baserait sur un fichier .proto qui fait office de DTD pour valider la cohérence du message mais aussi pour générer l’api cliente
Par exemple le person.proto suivant permetrrait de définir le format et les règles de validation des messages :
message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;
enum PhoneType {
MOBILE = 0;
HOME = 1;
WORK = 2;
}
message PhoneNumber {
required string number = 1;
optional PhoneType type = 2 [default = HOME];
}
repeated PhoneNumber phone = 4;
}
La particularité de protocol buffer est d’utiliser une api standardisée pour encoder / décoder les messages. Les utilisateurs de castor pour le XML ne seront pas dépaysés.
L’inconvénient est qu’on est obligé de compiler et générer les classes correspondantes au .proto qu’on veut utiliser.
L’avantage c’est que les compileurs Java, C++, et Python sont fournit par google. Un autre avantage et non des moindres c’est qu’on est sure lors de la génération d’un message que celui-ci est valide. Alors qu’avec du XML on peut très bien produire des messages non valides qui seront déclarés ensuite comme tels lors de leur validation… ou pas. Autre avantage de la compilation : la vitesse de traitement, en effet, une fois compilée, les classes qui manipulent les fichiers d’interchange sont plus rapides car elles savent exactement où les infos se trouvent alors qu’un parseur XML doit parcourir l’ensemble du fichier pour ensuite pouvoir accéder à son conetnu.
Bref voilà un nouveau projet très intéressant proposé à la communauté par google d’autant que sa maturité est avérée puisqu’utilisé comme format d’interchange au sein des serveurs googles pour gérer les indexs du moteur de recherche numéro 1 dans le monde.
A mon avis, le seul frein à l’adoption de ce nouveau format est le déploiement très large actuellement de XML notamment dans les bus ESB et dans les applications SOA. Cependant, la généralisation de ces bus de données tant à montrer la faiblesse de XML notamment au niveau de la taille des interchanges qui engorge littéralement ses canaux. Il se pourrait donc que les entreprises qui souhaitent optimiser leurs échanges décident petit à petit de migrer vers des bus de données protocol buffers qui devraient apporter les mêmes sécurités tout en étant plus simple à manipuler et moins coûteux en quantité d’information.
Pour en savoir plus : le site de Protocol Buffers
Weblogic 8.1 n’est pas supporté par les plugins serveurs de la plateforme WTP.
Cependant il est intéressant de pouvoir se connecter sur la JVM de weblo pour débuguer un projet en production par exemple, car j’ose imaginer que les nouveaux projets sont développés sur des serveurs plus à jours.
Il faut ensuite démarrer weblo en mode debug en ajoutant dans sa commande de lancement les valeurs :
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n
Ensuite, une fois weblogic démarré, on peut se connecter à la JVM en configurant une Remote Java Application dans le menu debug d’eclipse.
En java – comme la plupart des langages – il est très important de bien maîtriser les différents résultats d’une méthode.
De primes abord rien ne parraît plus trivial puisque la méthode déclare le type du paramètre retourné comme dans ce cas de figure :
public int ajouter (int a, int b)
Cependant, ça se corse un peu dès lors qu’on retourne un objet :
public String getParticipantName (int participantId)
En effet ce cas de figure peut retourner le nom du participant sous forme d’un objet String mais il peut également retourner null si aucun participant ne correspond à l’id donné en param.
Dans ce cas, il faudra tester obligatoirement que le résultat est différent de null avant de faire une quelconque opération dessus. Pour le développeur, de la méthode, retourner null signifie “je n’ai pas trouvé” ce qu’on me demande et me parraît être une valeur plus adéquat qu’une chaîne vide.
Si l’objet retourné est un tableau :
public ArrayList getParticipants(int epreuveId)
Dans ce cas de figure, je conseillerais au développeur implémentant cette méthode de retourner dans tous les cas un tableau même si celui-ci est vide. Ce qui signifierait texto : voici la liste demandée, elle est vide, plutôt que je n’ai rien à retourner. (dans ce cas je me demande s’il ne faudrait pas retourner la liste vide si c’est le cas et null dans le cas où on se rend compte que l’epreuveId est incohérent ?).
En tout état de cause lorsqu’on parcourera ensuite la variable retournée, on n’aura pas la mauvaise surprise de déclencher un NullPointerException.
Cas des RuntimeException :
private int divise (int a, int b)
La division pose un problème bien connu : celui de la division par 0. Cependant on peut imaginer – vu que la méthode est privée – qu’avant d’utiliser cette méthode, on aura au préalable géré les pré-conditions à son appel. Dans ce cas le développeur ne veut pas avoir a gérer un try catch alors qu’il sait que les paramètres sont déjà vérifiés. Toutefois si notre méthode divise venait à être utilisée dans le cas interdit, il faudrait lever une exception de type RuntimeException. Cette Exception ne nécessite pas d’être déclarée mais pourra cependant signaler la mauvaise utilisation de la méthode.
Cas des Exceptions :
public int divise (int a, int b) throws Exception
Ici, notre méthode devra pouvoir lever une Exception dans le cas où il y aurait une division par 0. En effet cette méthode est visible par tout le monde et on ne sera pas certain que tout ses utilisateurs auront vérifié les pré-conditions à son utilisation. La seule issue possible est le déclenchement de l’exception adéquate que l’utilisateur de la méthode devra obligatoirement prendre en compte.
Cas des arguments modifiés par référence :
public void removeTokensFromString(String stringToParse, String tokenToBeRemoved)
Imaginons que cette fonction doive parser la chaine “stringToParse” afin d’enlever toutes les occurences de “tokenToBeRemoved”, dans cas cas là certains développeurs n’hésitent pas à utiliser la possibilité du passage par référence pour manipuler directement le contenu de stringToParse.
Je reste persuadé qu’il faudra toujours préférer écrire ce genre de fonction de la manière suivante :
public String removeTokensFromString(String stringToParse, String tokenToBeRemoved)
et l’utiliser de la façon suivante:
String chaineToParse = “les avions sont dans le ciel bleu”;
chaineToParse = removeTokensFromString(chaineToPars, “bleu”);
plutôt que la première méthode qui s’écrirait :
String chaineToParse = “les avions sont dans le ciel bleu”;
removeTokensFromString(chaineToPars, “bleu”);
Voyez-vous des cas où cette deuxième façon d’écrire pourrait ne pas être appliquée ?
Quoiqu’il en soit l’utilisation et l’implémentation d’une méthode en java peut avoir maintes et maintes interractions sur l’exécution logique de votre code, il est donc primordial d’avoir conscience de tous ces principes.
Après avoir été contacté par Eric le webmaster de l’excellent site http://www.123sudoku.net/, je viens de tester mon solver sur “Al Escargot” la grille réputée la plus dure du monde.
Résultat : solution trouvée en 31 millisecondes en effectuant 420 itérations.
Donc si vous êtes amateur de grilles costaud :
1 x x x x 7 x 9 x
x 3 x x 2 x x x 8
x x 9 6 x x 5 x x
x x 5 3 x x 9 x x
x 1 x x 8 x x x 2
6 x x x x 4 x x x
3 x x x x x x 1 x
x 4 x x x x x x 7
x x 7 x x x 3 x x
Bon WE à tous.
Petit billet en forme de pense-bête à propos du format ultra restrictif du fichier MANIFEST.MF en Java :
Le fichier Manifest.mf permet de donner des information sur l’archive Java (JAR ou WAR).
La page chez Sun qui lui est consacrée est ici [popup]
Il permet entre autre de définir les librairies qu’utilise notre projet
Format lorsqu’on souhaite renseigner des librairies :
Manifest-Version: 1.0[CRLF]
Class-Path: ../lib/dom.jar[SPACE][CRLF]
[SPACE]../lib/fop.jar[SPACE][CRLF]
[SPACE]../lib/log4j-1_2_8.jar[SPACE][CRLF]
ATTENTION pour chaque library il faut insérer un espace en début et fin de ligne quant à la dernière ligne du manifest, elle doit être présente mais ne doit comporter aucun caractère (pas même un espace)
Je ne suis pas un très grand fan des sudokus, mais ça fait un moment déjà que je me demande s’il serait facile ou non de faire un programme pour les résoudre.
J’ai donc mis les mains dans le cambouis et voilà une appli java qui résoud tous les niveaux (enfin je crois) de ce jeu particulièrement à la mode actuellement.
Pour exemple, j’ai utilisé trois grilles et deux façon (algorithmes pour les intimes) – une plutôt brute force et l’autre un peu plus fine – pour résoudre la grille et voici les résultats :
Grille 1 : niveau normal
méthode 1 : 15ms et 874 itérations
méthode 2 : 15ms et 123 itérations
Grille 2 : niveau diabolique
méthode 1 : 47ms et 11586 itérations
méthode 2 : 16ms et 289 itérations
Grille 3 : niveau crazy
méthode 1 : 15ms et 162 itérations
méthode 2 : 2407ms et 104367 itérations
Comme on peut le constater les méthodes sont inégales, il faut dire que la grille diabolique ne comporte que 10 chiffres de départ ce qui peut expliquer l’avantage de la brute force.
Cette fin de semaine fut placée sous le signe du PDF via la bibliothèque FOP (lien vers le projet FOP de Apache) qui permet d’en générer via une source XML, un fichier de transformation XSLT et un fichier de présentation (formatation) FO.
Bref, je ne vais pas réécrire ce que d’autres ont mieux écrit que moi, je vous suggère donc si vous êtes confrontés à cette problématique d’aller voir les liens suivants :
Voilà avec ça on arrive à un résultat convainquant.
Et pour finir une blague de Guillaume : David Bowie et Lady Di ont deux fils comment les appellent-t-ils ?
La réponse : “Bowie Ken et Alain Di”.
Continuer la lecture ‘[XSL-FO] Génération de PDF depuis Java’
Je suis fan de la JavaDoc du coup je truffe mes devs PHP de @return et autres @param (pour ne citer qu’eux) et maintenant avec PHP5 je peux ajouter des @access et autres @static et @abstract … bref tout ça pour dire que j’ai trouvé l’outil ultime : j’ai nommé doxygen, il permet de générer la doc en HTML, RTF, PS, PDF, man Unix. Doxygen est distribué sous license GPL.
Bref pour l’avoir testé à l’instant, je dois dire que le résultat surpasse ce que j’obtenais avec le parser de phpDoc (http://www.phpdoc.de à ne pas confondre avec les autres parseurs comme phpdocumentor par exemple.)
Bref, si vous ne développez pas avec un ide ayant cette fonctionnalité intégrée, je vous le conseille.
Ah oui j’allais oublier, ici (developpez.com) vous pouvez trouver un bon comparatif des solutions de documentations pour PHP.
On sunday afternoon I spent one hour trying to make my first steps in Java’s world.
All I can say is that sun naming conventions as regards their products are very ambiguous : for example J2SE 5.0 is the successor of J2SE 1.4.
Whatever I decided to use J2SE 5.0 with netbeans which is recommended by sun as IDE.
Apparently this package includes Tomcat because after some clicks I launched a demo servlet in my favorite browser (Firefox of course !)
So I dont take much tour around netBeans4 but I will as soon as possible.
I planned to try Eclipse but from what I’ve seen so far NetBean is eye friendly. That’s a good point.
To be continued…
Commentaires récents