Depuis J2EE5 et la spécification EJB (JSR-318), l’annotation @javax.ejb.EJB permet d’injecter une instance d’un EJB dans une variable.
Grâce à J2EE6 et la spécification Dependency Injection (JSR-330), l’annotation @javax.inject.Inject permet d’injecter n’importe quelle sorte de POJO (Plain Old Java Object) dont, bien entendu, des EJB dans une variable. Quelle annotation utiliser ?
Dans la plupart des cas, il est préférable d’utiliser l’annotation @javax.inject.Inject au lieu de @javax.ejb.EJB car elle est globale à toutes les sortes d’objets. Il faudra impérativement utiliser @javax.ejb.EJB lorsque :
- Le conteneur où est déployée l’application n’est pas compatible avec CDI
- L’EJB à injecter est un EJB remote
Comme indiqué dans la documentation de référence de Weld, si l’on souhaite utiliser l’annotation @javax.inject.Inject pour injecter un EJB remote, il est nécessaire de passer par un autre objet référenceant l’EJB remote via l’annotation @javax.ejb.EJB :
@Produces @EJB(ejbLink="../their.jar#PaymentService")
PaymentService paymentService;
Pour plus d’information, lire la documentation de Weld ou ce message intéressant sur le forum JBoss : https://community.jboss.org/thread/179388?start=15&tstart=0,
Jusqu’à présent, pour gérer plusieurs exceptions dans un bloc try/catch, il fallait un bloc catch par type d’exception. Il était bien entendu possible de “rattraper” une exception de haut niveau, de découvrir son type d’instance avec l’opérateur instance of puis de décider comment la traiter ou la relancer.
Désormais, il est aussi possible de déclarer plusieurs types d’exceptions dans un même bloc catch. Voici un exemple :
try {
...
} catch (IOException e) {
System.out.println(e.getMessage());
} catch (MonException e) {
System.out.println(e.getMessage());
} catch (Exception e) {
System.err.println(e.getMessage());
}
// A partir de JavaSE 7
try {
...
} catch (IOException | MonException e) {
System.out.println(e.getMessage());
} catch (Exception e) {
System.err.println(e.getMessage());
}
Avec Java 7, beaucoup de nouveautés sont arrivées. L’opérateur en diamant, par exemple, permet d’éliminer une redondance dans la rédaction du code source lorsque l’on déclare une collection. Par exemple avant Java 7 il fallait déclarer sa collection ainsi :
List<MaClasse> maListe = new ArrayList<MaClasse>();
Maintenant, il n’est plus nécessaire de préciser le type de la collection dans la l’instanciation :
List<MaClasse> maListe = new ArrayList<>();
Dans J2EE6 il existe deux spécifications qui parlent de scopes applicatifs : JSR 314: JavaServer Faces 2.0 et JSR 299: Contexts and Dependency Injection for the JavaTM EE platform (CDI). La difficulté vient du fait que ces scopes ont le même nom et la même fonction :
- @javax.faces.bean.RequestScoped (JSF) et @javax.enterprise.context.RequestScoped (CDI).
- @javax.faces.bean.SessionScoped (JSF) et @javax.enterprise.context.SessionScoped (CDI).
- @javax.faces.bean.ApplicationScoped (JSF) et @javax.enterprise.context.ApplicationScoped (CDI).
Lesquels utilisés ? Comme pour certaines autres annotations qui semblent dupliquées dans J2EE, ces annotations sont identiques, elle diffèrent uniquement suivant le contexte de déploiement. JSF2.0 propose ses propres annotations pour laisser la possibilité aux développeurs de déployer des applications JSF2.0 dans des conteneurs dépourvus de CDI (Tomcat par exemple) mais en conservant l’avantage de l’outjection proposée par la JSR CDI.
Sachant cela, la sélection de ces annotations doit se faire en fonction du contexte de déploiement. Il faut bien entendu préférer les annotations CDI à JSF si le conteneur est compatible avec la JSR-299.
Il existe cependant un scope proposé par JSF2.0 et inexistant dans CDI : @ViewScoped. Il est possible dans ce cas d’utiliser la librairie DeltaSpike JSF ou Seam 3 Face Module pour avoir accès à une version CDI du scope.
D’après le forum de zeroturnaround, JRebel 5.5.0 n’est pas compatible avec Wildfly8.0.0.CR1. Pour le rendre compatible il faut récupérer la dernière version de développement de JRebel (nigthly build) sur leur site internet : http://zeroturnaround.com/software/jrebel/download/early-access/.
Pour mettre à jour la librairie utilisée par le plugin JRebel dans eclipse , il faut se rendre dans l’écran de configuration JRebel : Help -> JRebel Config Center. Ensuite saisir le chemin de la librairie dans l’onglet Overview. Sinon, par défaut, le plugin utilise la version embarquée de la librairie.
Lorsque l’on débute en J2EE il est parfois difficile de voir la différence entre certaines annotations. Elles proviennent souvent de spécifications (JSR) différentes et peuvent avoir un rôle similaire ou totalement identique. Certaines fois, il s’agit uniquement d’une différence de contexte dans lequel le code est développé ou déployé.
Les annotations suivantes sont utiles pour déclarer des objets Java qui vont être accessibles dans le langage EL via les symboles #{} (on parle d’outjection par opposition à injection).
@javax.faces.bean.ManagedBean
Cette annotation arrive avec la JSR-314 JavaServer Faces 2.0. Grâce à elle, il n’est plus nécessaire de déclarer les Managed Bean JSF dans le fichier XML faces-config.xml. Elle n’est utile que lorsque le l’application développée est déployée dans un contexte où le conteneur CDI n’existe pas, comme Tomcat par example.
De plus, elle peut facilement être confondue avec l’annotation suivante @java.annotation.ManagedBean.
@javax.annotation.ManagedBean
Cette annotation est définie dans la JSR-250. Elle est utilisée pour déclarer un managed bean spécifié dans la JSR-316. Il ne faut pas confondre avec les managed bean JSF. Le principe de la JSR-316 est de pouvoir transformer n’importe quel POJO (Plain Old Java Object) en objet pouvoir avoir un cycle de vie, des intercepteurs, etc.
Dans un contexte CDI, cette annotation est obsolète car le principe du CDI est de transformer tous les POJO en Managed Bean. Donc cette annotation n’est pas du tout utile. Elle n’aura d’ailleurs aucun impact visible sur l’exécution du code.
@javax.enterprise.inject.Model @javax.inject.Named
L’annotation @Model est équivalante à l’annotation @Named à laquel il a été rajouté le contexte @RequestScoped (@javax.enterprise.context.RequestScoped).
Ces annotations proviennent de la JSR 299 “contexts and dependency injection” (CDI). Cette JSR offre beaucoup plus de possibilités d’utilisation que celle sur JSF2.0. Dans un contexte où une application est déployée dans un conteneur compatible CDI il est donc préférable d’utiliser les annotations CDI plutôt que JSF2.0.
Conclusion
Le choix de l’annotation à utiliser dépend essentiellement du conteneur où l’application sera déployée. Il est toujours préférable d’utiliser les annotations provenant de la JSR-299 (CDI) dans le cas où le conteneur est compatible avec CDI.
Pour plus d’information cet article est très intéressant : Is @javax.faces.bean.ManagedBean Dead on Arrival?
Il me semblait que faire un fond en dégradé avec CSS3 était à la portée de tous. En effet ce n’est pas très compliqué, mais, selon ce que l’ont souhaite obtenir, il peut y avoir beaucoup de paramètres à prendre en compte. Par hasard, j’ai découverts un site internet qui propose une interface pour générer ses propres dégradés compatibles avec tous les navigateurs : http://gradients.glrzad.com/.
Le principe est simple, il faut choisir
- le nombre de couleurs du dégradé,
- l’orientation et la position de la ou les ruptures de couleur
- la rapidité de passage d’une couleur à l’autre
Ensuite, il suffit de copier le code CSS généré dans sa propre feuille de style.
Le connecteur m2e de JRebel ne s’installe plus à partir du marketplace eclipse. Pour l’installer il faut passer par la mise à jour manuelle. Dans les menus de l’IDE : Help -> Install New software…
Le site d’update est : http://update.zeroturnaround.com/update-site. Le plugin à installer : JRebel m2eclipse.
Cette information date déjà de quelques mois, mais je viens de la découvrir : il existe une version gratuite de JRebel (https://social.jrebel.com). Ce logiciel permet aux développeurs Java d’éviter les redéploiements à répétition de leurs applications grâce à un système de synchronisation du code développé et du code déployé.
Bien entendu, il existe des contraintes :
- Disponible uniquement pour les développements non commerciaux (impossible à utiliser en entreprise par exemple)
- Publication mensuelle de statistiques sur Tweeter ou/et facebook
Il y a quelques mois, on m’a fait découvrir le plugin eclipse MoreUnit. Comme je le trouve très pratique, je profite de mon blog pour en parler. Il permet de gagner du temps pour le développement et l’exécution des tests unitaires. Il facilite aussi l’association entre les classes destinées à l’exécution et celles qui vont les tester. Ce plugin est disponible sur le marketplace.
Si l’option Decorate Classes with Test Case est activée (Window > Preferences… > General > Appearance > Label Decorations), les classes qui sont testées sont représentées avec un icon différent :
La même marque verte apparaît au niveau de la marge de l’éditeur Java au début des méthodes testées :
A partir d’une classe, un menu contextuel permet les actions suivantes :
- Ouvrir la classe de test associée
- Générer la classe de test si celle-ci n’existe pas
- Exécuter la classe de test en entier
- Exécuter les méthodes de test associées à une sélection de méthodes de la classe d’origine
Le plugin sait aussi prendre en compte les refactorings de la classe testée :
- Si la classe testée est renommée, la classe de test est renommé elle aussi
- Idem, si la méthode testée est renommée, les méthodes de test le sont aussi
- Si la classe testée change de package, la classe de test change aussi de package
Enfin, la dernière fonctionnalité que je trouve très utile dans certains contextes, MoreUnit peut générer les mocks des objets utilisés dans la classe testée. Il est compatible avec Mockito et EasyMock. Il ne reste plus qu’a les paraméter.
Comments (0) 
