Soft qui peut

Android game : Paratrooper

2010-08-19T01:50:00.000-07:00

Paratrooper is the android adaptation of the famous amstrat game.
Use your finger to destroy paras, helicopters, bombers, and much more..

Xp point based system to upgrade your cannon specs.

To get the game : Download

Split n Go !

2010-04-21T23:45:00.001-07:00

Split N Go is a high addictive android game.

Draw lines with your finger to reduce the surface of the screen without crossing ball's trajectory. When you 'll reach about 75% you ll get to the next level.

Here is a preview video :

PS : Level 7 is NOT a bug, it's a challenge!

Space Sim sur Android

2010-04-18T09:07:00.001-07:00

Space sim is a gravity game that allows you to play with planets and satellites on your android phone !

Get the Lite version !

Features :

Add satelites and planets with your finger.
Repulsive planets
Multitouch zooming
Sat. cam to focus camera on a satellite (use trackpad)

how to :

add a satellite : simply draw a ligne on the screen with your finger. Longer is the line, faster will be the satellite !
add a planet : kepp pressing the screen during 5 sec where you want to add a planet. You can choose the kind of planet (repulsive or not) in the menu.

Download now : Download from market

Sortie de bea workshop 10.2

2008-03-03T04:12:00.000-08:00

Bea nous offre la nouvelle release de son ide commercial basé sur Eclipse.
En attendant la nouvelle version de son serveur d'application qui devrait gérer(enfin) JSF 2.0, BEA s'est concentré sur l'IDE. Au menu un correctif de beug, une amélioration des performances, l'intégration flex et le support du "tuxedo control" que nous retrouverons dans cette version 10.2.

Nouveauté, une couche au dessus des produits BEA qui permet de lancer et de visualiser les produits bea installés sur le poste : WorkSpace studio.

Workshop deviendra t'il un IDE utilisable sereinement par les développeurs, avec un serveur simplifié sur le poste développeur plus rapide à démarrer et une consommation mémoire raisonnable (< à 2Go) ? Ce sera en tout cas la clé pour une adoption massive du produit. Pour l'annonce en anglais c'est ici : http://dev2dev.bea.com/blog/phumphrey/archive/2008/02/the_fastest_wor.html

Télécharger un fichier via JSF

2008-02-11T02:50:00.000-08:00

Question du jour: comment renvoyer un fichier (généré à la volée ou du disque) au navigateur web à partir d'un back bean JSF?

Prendre un FacesContext, extraire l'objet response de son external context. Faire revenir la response en la castant en HttpServletResponse. Ajouter quelques headers http (pour le nom du fichier), un type mime (pour le comportement du navigateur). Ajoutez un flux quelconque (généré à la volée ou lue a partir d'un fichier selon les goûts), et retirez immédiatement (responseComplete) pour éviter les ennuis.
Compilez, déployez et savourez ...

En mode intelligible ça donne ceci :


public void doTestStream(ActionEvent ae) throws IOException
    {
        FacesContext context = FacesContext.getCurrentInstance();
        ExternalContext ec = context.getExternalContext();
        HttpServletResponse response = (HttpServletResponse) ec.getResponse();
        response.reset();
        response.setContentType("application/csv");
        response.setHeader("Content-Disposition", "filename=Demo.csv");       
        response.setHeader("Content-Transfer-Encoding", "binary");
        ServletOutputStream sop =  response.getOutputStream();
        sop.write("hello;csv;world".getBytes());
        sop.flush();       
        context.responseComplete();       
    }

Kodo Optimistic Exceptions

2008-01-15T00:21:00.000-08:00

Aujourd'hui, une simple astuce dans l'utilisation de Kodo. Dans le cas de table avec des relations parent-enfants, il est assez courant de vouloir utiliser des supressions en cascade.
Pour ce faire on configure le CascadeType dans le bean entity.

Je suis tombé hier sur une exception de type OptmisticException dans le cas d'une suppression en cascade :
<1.0.0> org.apache.openjpa.util.OptimisticException: Optimistic locking errors were detected when flushing to the data store. The following objects may have been concurrently modified in another transaction:

Il s'avère que Kodo a l'étrange idée de se tirer une balle dans le pied en tentant de supprimer d'abors l'enregistrement parent et ensuite les enfants...

Pour palier à ce soucis, je vous invite à rajouter dans votre persistance.xml la petite ligne qui suit :

Merci Bea d'agrémenter mes journées de travail par de longues et infructueuses recherches désespérées de la petitie ligne de configuration servant à modifier un comportement qui, bien que nécessaire dans 99% des cas, n'est pas activé par défault.

Injection EJB avec JSF1.1 solution 2

2007-12-07T00:41:00.000-08:00

Nouvelle solution plus propre (ca fera plaisir à Alexandre) et plus performante pour effectuer une injection @EJB dans un managed bean (ou back bean) JSF. L'utilisation d'un lookup local tout simplement (bien que sur Workshop ce soit pas du gâteau).

Une petite classe donc qui, avec sa simple méthode à appeller dans le contructeur de votre back bean vous permettra par réflexion d'effectuer un context lookup vers votre ejb (Champs @EJB public uniquement). Toujours en attendant l'injection @EJB dans le nouveau WorkShop.

télécharger la classe java

Pour cerain il peut se produire une erreur de lookup du style :

javax.naming.NameNotFoundException: While trying to look up comp/env/Addition/Local in /app/webapp/TEST_JSF_EBJ/12227708.; remaining name 'comp/env/Addition/Local'

Pour résoudre ce problème j'ai simplement ajouté un ServletContextListener à mon application web dans laquelle je référence mes ejb . Après le lookup local dans les back beans fonctionne a merveille...

public class testListener implements ServletContextListener {

@EJB(name = "Addition/Local")

public AdditionRemote ar;

public void contextDestroyed(ServletContextEvent arg0) { }

public void contextInitialized(ServletContextEvent arg0) { }

}

Exemple d'utilisation :

@EJB(name = "Addition/Local")

public AdditionRemote ar; // is va être injecté dans le constructeur

public testBackBean() {

fr.sihm.common.ejblocator.EJBLocator.injecterMesEJB(this);

}

public String getResultEJB() // on teste

{

if (ar == null) {

return "NOT BOUND";

} else {

return "Bouded , result = " + ar.additionner(5, 5);

}

Injection d’un EJB dans un back bean JSF 1.1

2007-12-05T05:36:00.000-08:00

Dans sa version 10.1, BEA workshop studio propose de base de faire du JSF 1.1. Or, dans la spécification JSF 1.1, l’injection d’EJB n’est pas possible dans les back-beans.

En attendant la nouvelle version de workshop qui devrait permettre d’utiliser JSF 1.2 facilement (oui c’est déjà possible mais galère) et donc l’injection dans les back beans, je vous propose un petit « hack » maison pour permettre de ne pas trop salir vos managed beans tout en ayant un semblant d’injection (Le canada dry de l'injection EJB).

Le fonctionnement est simple, on crée un servlet listener qui possède une référence vers tous les ejb que vous utiliserez dans l’application. La norme JSF 1.1 permettant l’injection dans les servletfilters, ces références seront peuplées lors de l’exécution. Dès lors, notre tâche consistera à copier les références dans le servletcontext pour que nos back beans aient accès aux valeurs injectées.

Je vous fourni donc une classe qui par réflexion va analyser tous les champs public qui contiennent l’annotation @EJB et qui écrira (pour le listener) ou lira (pour le back bean) la valeur dans le ServletContext.

Utilisation :

Notre Listener comportra une réference vers tous les EJB utilisés (un seul dans mon exemple), et l'implémentation de la méthode contextInitialized sera toute simple :

public class testEJBInjectionListener implements ServletContextListener {

@EJB(name = "Addition/Local")

public AdditionRemote ar;

public void contextDestroyed(ServletContextEvent arg0) {

// TODO Auto-generated method stub

}

public void contextInitialized(ServletContextEvent arg0) {

tools.EJB_Initialiser.saveMyEJBs(arg0.getServletContext(),this);

}

Du coté du back bean, rien de plus compliqué. On fait une référence vers les EJB que l'on souhaite utiliser en conservant l'injection :

public class testBackBean {

@EJB(name = "Addition/Local")

public AdditionRemote ar;

public testBackBean()

{

tools.EJB_Initialiser.injecterMesEJB(this);

}

La classe utilitaire InitialiserEJB fesant le reste : télécharger la classe.

Au niveau des performances ce n'est pas terrible du tout car cela effectue un lock sur l'instance des l'EJB coté serveur (car une seule instance dans le contexte application), aucun accès concurant ne sera donc possible et il faudra attendre gentiment son tour pour accéder au bean session. A utiliser donc en attendant JSF 1.2 !

Tutoriel .net sur les BuildProvider

2007-11-23T06:06:00.000-08:00

Ayant délaissé visual studio pour éclipse ces derniers mois, je souhaitait "garder la main" en .net tout en vous montrant une facette bien peu connue de .net : les BuildProviders.

Qu'est-ce qu'un build provider ?

Un build provider se présente sous la forme d'une classe héritant de System.Web.Compilation.BuildProvider et permettant de compiler pendant le développement des fichiers de la solution. Les classes ainsi créées sont accessibles via l'intellisense dans la solution.

Pour bien cerner toute la puissance de cette technologie, je vous propose d'étudier le cas d'un provider permettant de simplifier l'utilisation des sessions utilisateurs.

Trop souvent dans un projet web, les sessions deviennent rapidement un "foure-tout". De plus, c'est une bonne pratique que d'avoir un fichier recensant l'utilisation de la session dans le projet. Nous allons donc créer un build provider qui, à partir d'un fichier xml de la solution, génèreralirer et d'écrire dans la session sans ses soucier du nom des clés ou du casting.

Structure du fichier descriptif de session :

Pour commencer, créez un nouveau site asp.net. Ajoutez à la solution une nouvelle biblothèqueBuildProviderSession" .

Ajoutez ensuite une nouvelle classe nommée BPSession et héritant de System.Web.Compilation.BuildProvider

Nous allons implémenter 3 méthodes de la classe BuildProvider.

CompilerType : propriété qui spécifie le type de compilateur à utiliser par visual studio.

GenerateCode : méthode dans laquelle nous renverrons le code c# à compiler.

GetGeneratedType : méthode ou nous renverrons à visual studio le type généré.

Notre Build Provider est maintenant terminée, nous allons l'utiliser dans le projet web de la solution.

Pour ce faire, rien de plus simplen ajoutez au web.config (créez le si nécessaire) ces quelques lignes (sous system.web) :

La partie extension détermine pour quel types de fichier visual studio appellera notre compilateur.

Vous pouvez maintenant créer dans le répertoire app_code du site web un fichier avec l'extention dvp respectant le schéma du fichier xml précédent.

Après avoir compilé la solution (avec succès normalement), allez simplement dans le code d'une page web, défault par exemple. Et la surprise, notre classe CurrentSession est disponble :

Conclusion

Les BuildProviders sont des outils très puissants. L'exemple que j'ai choisi est simple et son intérêt est limité. Cependant, dans le cadre de développement de frameworks, cette technologie offre un outil sans égal pour simplifier la vie du développeur. Je proposerais plus tard un tutoriel sur l'écriture d'une interface graphique pour générer le fichier descriptif des sessions. Interface qui sera bien sur intégrée à Visual Studio :)

Télécharger la classe BPSession

Utilisation des JavaAgents

2007-10-30T07:21:00.001-07:00

En étudiant le fonctionnement de KODO en standalone, j’ai été amené à utiliser un concept qui m’était inconnu : les JavaAgents. C'est une nouveauté de Java 5 pour laquelle on trouve très peu de documentation. Je vous propose donc d'expliquer simplement son utilisation.

Définition

Un JavaAgent est une librairie « pluggable » qui tourne dans une JVM embarqué (celle du programme exécuté) et qui intercepte les chargements de classes. Cela permet donc de suivre le processus de chargement des classes d’un programme java et, si nécessaire, de modifier à chaud le comportement de la classe (mécanisme d’intercession).

Concrètement un JavaAgent se présente sous la forme d’un simple JAR contenant une classe implémentant une méthode :

public static void premain(String agentArgs, Instrumentation inst)

Le premier argument de cette méthode est un String représentant les arguments à passer à l’agent (à parser sois même avec pipe, délimiteur,…). Le deuxième est l’instance d’Instrumentalisation. C’est grâce à cette classe que l’on ajoute les transformers voulus.

ClassTransformer

Les classes implémentant l’interface ClassFileTransformer sont créées pour effectuer des modifications dans le bytecode de classes existantes. Leur implémentation est très simple puisqu’il suffit d’implémenter l’unique méthode de l’interface ClassFileTransformer.

Création d’un agent java simple

Dans cet article je vous propose de créer un agent java très simple. Il aura pour but l’affichage dans la sortir standard des classes qui sont chargée par le programme. Pour arriver à notre objectif nous aurons besoin de créer l’agent, son ClassFileTransformer, et d’extraire le tout dans un JAR correctement formaté.

Dans un nouveau projet java créez une classe myJavaAgent comme ceci :

package fr.demo.testAgent;

import java.lang.instrument.Instrumentation;
import fr.demo.testTransformer.TestClassTransformer;

public class myJavaAgent {
public static void premain(String agentArgs, Instrumentation inst)

{
inst.addTransformer(new TestClassTransformer());
}
}

La seule opération de l’agent est d’ajouter un classtransformer à l’instance d’instrumentalisation de la JVM du programme executé.

Code du class transformer :

package fr.demo.testAgent;
import java.lang.instrument.ClassFileTransformer;

import java.lang.instrument.IllegalClassFormatException;

import java.security.ProtectionDomain;

public class EzClassTransformer implements ClassFileTransformer {

public byte[] transform(ClassLoader loader, String className,

Class classBeingRedefined, ProtectionDomain protectionDomain,

byte[] classfileBuffer) throws IllegalClassFormatException {

System.out.println("Je charge la classe :" + className);

return classfileBuffer;

}

Comme vu précédement, l’interface ClassFileTransformer se résume en une méthode à implémenter : transform. Cette méthode passe en paramètre la classe avant qu’elle soit chargée par la JVM. Elle offre la possibilité de modifier le comportement de la classe en ayant comme paramètre de retour un tableau de byte correspondant à la classe compilée. Pour l’instant nous nous contenterons simplement d’afficher que la classe est chargée en renvoyant directement la classe passée en paramètre sans modification.

Création du JAR

Un java agent se présentant sous la forme de JAR, il nous faut donc créer un JAR contenant l’agent java et le classfiletransformer (via éclipse, click droit sur projet, export, java archive). Dans le fichier META-INF/MANIFEST.MF du jar il faut ajouter l’entrée :

Premain-Class: fr.demo.testAgent.myJavaAgent

Cette entrée permet de définir à la JVM la classe du JAR jouant le rôle de l'agent (bootstrap class).

Une fois le JAR crée il ne nous reste plus qu’à le tester. Pour ce faire prenez une application java de votre choix (console, swing…) et éxécutez la simplement en ajoutant l’argument (via éclipse « open run dialog » et « arguments ») :

-javaagent:lienversjar .

Conclusion

Les AgentsJava sont très utiles pour ajouter des crochets au chargement des classes de la JVM. Certes l’utilisation que nous en avons fait dans cet article est somme toute limitée, mais les classfiletransformer offrent des possibilitée que vous n’osez même pas imaginer! Je proposerais prochainement un article montrant ce méchanisme couplé avec BCEL pour modifier a chaud les bytecode des classes : une façon de voir cette technologie d’un aspect(J?) différent (comprendra qui pourra).

Bean Entity StandAlone recherche CRUD générique

2007-10-26T02:59:00.000-07:00

Petite classe java utile rédigée par mes soins qui vous permettra de ne pas perdre de temps avec vos opérations de CRUD (Create Read Update Delete ) pour les entityBeans Standalone.

Télécharger la classe

Pour l'utiliser il suffit simplement d'hériter de cette classe et d'ajouter un contructeur. Exemple avec une DAO d'un objet "Secteur" :

public class SecteurDAO extends GenericDAO {


public SecteurDAO(String entityManagerName)
{
super(entityManagerName,Secteur.class);

}
}

Bean Entity

Les beans entity doivent posséder des namedqueries pour définir comment les sélectionner. Exemple :

@Entity
@NamedQueries(value ={
@NamedQuery(query="Select a from Agence a where a.id = ?1"
,name="SelectByIdAgence") ,
@NamedQuery(query="Select a from Agence a"
,name="SelectAllAgence")})
public class Agence implements Serializable {

Il est important de garder le même nom dans les NamedQueries :SelectById et SelectAll + nom de la classe. On ajoute le suffixe de la classe car on ne peut pas avoir deux mêmes noms pour des requêtes au sein d'une même unité de persistance : Merci KODO ...

Limitations
Cette classe ne fonctionne que pour les tables ayant une clé primaire non composée (je ferai plus tard une RTB "Release to Bloggers" en ajoutant un nombre de paramètres variable pour la sélection).