Qu'est ce qu'on se fait ch ... !

Aller au contenu | Aller au menu | Aller à la recherche

Pourquoi je suis passé sur Netbeans

Voila quelques raisons qui m'ont fait choisir netbeans comme mon ide de prédilection :

La gestion des plugins est beaucoup plus intégré

Pas besoin d'aller sur un milliard de sites pour récupérer un plugin. Tout est centralisé!

Le support de Maven est natif

Et oui, par rapport à eclipse, le support des projets maven est natif. Quand vous ouvrez un projet maven, netbeans prend en compte automatiquement la configuration des fichiers pom.xml et substitue maven aux builds ant livrés par défaut.

Une seule gestion du classpath

C'est la ou eclipse pêche.... Dans un vrai projet, il y a plusieurs niveaux de classpath à gérer : le classpath pris en compte dans eclipse et celui de maven. Vu que la majorité des problèmes JAVA est lié à la configuration et la gestion du classpath, ca m'économise pas mal de temps.

C'est roots

Oui, eclipse /wtp est peut être trop intégré pour moi, j'aime assez être proche de la configuration cible ( build maven) et exclure de mes résolutions de pb l'IDE.

Ce qui manque encore

  • Pas mal de fonctionnalités d'édition et refactoring où eclipse est encore loin devant. Peut être qu' intellijidea est meilleurs mais bon netbeans est libre et gratuit.
  • Un support facelets digne de ce nom
  • Un support seam :D
  • Une bonne complétion dans les annotations JPA et JSF
  • Un support de tous les frameworks JSF dans l'editeur graphique

Un quatrième profil de binding pour JBOSS AS

Juste un post pour ceux qui souhaitent rajouter un quatrième profil dans le fichier de binding de JBOSS .

Voila un profil qui fonctionne. enjoy

Le plugin maven jaxws en action

Voila résumé en quelques lignes les différentes manipulations que j'ai effectué sur mon projet maven pour intégrer des services web:

D'abord j'ai crée un module à part entière qui centralise les sources générés à partir des fichiers WSDL. Dans ce projet de type jar

	<!-- Paramètres généraux -->
    <modelVersion>4.0.0</modelVersion>
    <artifactId>wsclient</artifactId>
    <name>wsclient</name>
    <description />
    <packaging>jar</packaging>
    <version>2.1.2-SNAPSHOT</version>
j'ai attaché à la phase generate-sources la génération des STUBS à partir des fichiers WSDL.

Génération des couches d'appel

La seule configuration "exotique" que j'ai apporté est la configuration par package . Pour faire bref, un package = 1 service web. Logiquement, on n'a pas trop à faire ca car les objets doivent être factorisés. Mais bon vu la techno préhistorique que j'ai en face, je n'ai pas trop le choix

Pour que le plugin jaxws s'exécute bien, il faut faire la configuration suivante :

 <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxws-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <id>01</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>wsimport</goal>
                        </goals>
                        <configuration>
                            <verbose>true</verbose>
                            <packageName>fr.monpackage.ws.1</packageName>
                            <sourceDestDir>${basedir}/src/main/java</sourceDestDir>
                            <staleFile>${project.build.directory}/jaxws/stale/.stale1Flag</staleFile>
                            <wsdlFiles>
                                <wsdlFile>01.wsdl</wsdlFile>
                            </wsdlFiles>
                        </configuration>
                    </execution>
                    <execution>
                        <id>02</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>wsimport</goal>
                        </goals>
                        <configuration>
                            <verbose>true</verbose>
                            <packageName>fr.monpackage.ws.2</packageName>
                            <staleFile>${project.build.directory}/jaxws/stale/.stale2Flag</staleFile>
                            <sourceDestDir>${basedir}/src/main/java</sourceDestDir>
                            <wsdlFiles>
                                <wsdlFile>02.wsdl</wsdlFile>
                            </wsdlFiles>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Remarque : la personnalisation du fichier stale est obligatoire

Nettoyage des fichiers générés

Pour automatiser la suppression des fichiers générés au moment de l'appel du plugin clean ,j'ai apporté la configuration suivante :

 <plugin>
                <artifactId>maven-clean-plugin</artifactId>
                <configuration>
                    <filesets>
                        <fileset>
                            <directory>${basedir}/src/main/java</directory>
                            <includes>
                                <include>**/**</include>
                            </includes>
                        </fileset>
                        <fileset>
                            <directory>${basedir}/src/wsdl</directory>
                            <includes>
                                <include>*.wsdl</include>
                            </includes>
                        </fileset>
                    </filesets>
                </configuration>
            </plugin>

Inclusion dans l'EAR

A l'instar des autres JARS, j'ai inclus l'artifact wsclient dans mon ear en tant que MODULE JAR

                        <jarModule>
                           <groupId>monpackage</groupId>
                           <artifactId>wsclient</artifactId>
                           <bundleFileName>wsclient.jar</bundleFileName>
                           <includeInApplicationXml>true</includeInApplicationXml>
                       </jarModule>

...

                   </modules>

Vu que je suis sous JBOSS, je n'ai pas à m'occuper des inclusions de CLASSPATH dans les fichiers MANIFEST :)

JAVA EE vs Services WEB & SIEBEL

Quand on fait des services web on se dit, c'est cool l'intéropérabilité!!! Surtout quand des gars de l'avant vente font éloge de la rolls des CRM ( quand je compare siebel à une rolls, c'est parce que c'est très cher et très lourd, comme la voiture)

Bref, voici en quelques mots les écueils que j'ai rencontré et rencontre encore actuellement:

Les standards

Tout d'abord, il a fallu se pencher sur le support des standards. La je me suis dit on part sur de bonnes bases :

  • SOAP 1.1 ( un peu vieux, mais bon je n'ai pas à gérer d'attachements ) ,
  • WS-I BASIC PROFILE 1.1.

A ce niveau on était compatible avec JAXWS et la stack de JBOSSWS 2.0.5 ( livrée avec JBOSS AS 4.2.3.)

Les schémas de données

Le premier problème est venu avec la gestion des données: SIEBEL me fournit à chaque fois un WSDL composé de 2 ou 3 schémas XML qui se font référence mutuellement. Et ca ... WSIMPORT n'aime pas trop. Pour preuve, l'erreur :

src-resolve: Cannot resolve the name  to a(n) 'element declaration' component

La seule résolution que j'ai trouvée était de placer tous les objets dans le même namespace et de fusionner les différents schémas. Je sais ca fait brutal, mais je n'ai trouvé que ca pour l'instant....

La gestion des virtual host

Le but ultime serait de faire tourner tout ce petit monde derrière un frontal web avec un virtual host qui changerait de nom selon l'environnement ( transcendant n'est-ce pas ?) Le seul moyen que j'ai trouvé pour l'instant, et qui ne me plait guère, est d'utiliser une annotation propriétaire JBOSSWS : @WebContext . J'essaye de voir sur les forums si il existe une autre solution ...

Réinitialiser la bonne version d'un projet dans MAVEN

Il arrive - je vous demande un maximum d'imagination :-) - que vous ayez échoué la première exécution de la commande mvn release:prepare et que même après avoir lancé un mvn release:clean, les fichiers pom.xml soient vérolés et n'indiquent pas la bonne version du projet exemple :


<version>2.0.1</version>

et non


<version>2.0.1-SNAPSHOT</version>

Pour rétablir, soit vous le faites à la main dans tous les fichiers. Dans le cas d'un projet JAVA EE, ca peut s'avérer fastidieux ou le faire avec PERL :-) Voici la ligne de commande

 $ find . -name "pom.xml" -exec perl -p -i.old -e "s/2.0.1/2.0.1-SNAPSHOT/g" {}\;

En espérant que ca aidera quelques développeurs malchanceux dans leur versions du vendredi soir !

Oracle rachète SUN

Ce qui devait arriver, arriva. Oracle rachète SUN pour un peu plus de 7 millilards de dollars us.

Outre le choix d'un serveur applicatif JAVA : BEA, Glassfish ou OAS - personnellement mon choix se porte sur glassfish :) . Il reste pas mal d'interrogations sur le reste de l'activité de SUN, spécialement sur le monde open-source : Opensolaris, Openoffice, virtual box, mysql ,....

Opensolaris va etre en concurrence avec Unbreakable Linux, mysql avec Oracle XE. La plus grosse interrogation réside sur le futur de JAVA et de sa communauté. Que va devenir le JCP. Est ce que le fait d'avoir passé JAVA en GPLv3 assurera la pérénnité de cette technologie. La suite dans le prochain épisode!

Bref, après le rachat de BEA, Oracle va passer encore pas mal de temps à digérer toutes les acquisitions et pondre une offre fusion toujours aussi ingérable...

Java comme langage de développement pour la plateforme google app engine

Ca y'est ! Après Python, Google ajoute le langage JAVA dans son hébergement Google App Engine. [1]

Pour ceux qui ne connaissent pas, google app engine permet d'héberger des applications écrites en Python et maintenant en JAVA. Google fournit un SDK et une documentation.

Bien sûr, on ne pourra pas tout faire et installer (ex. hibernate, jasper reports, ...). Mais je trouve que cette solution permet de reboucher un grand vide dans l'hébergement JAVA gratuit (limité certes mais pouvant convenir à quelques petites applications).

Coté API on y retrouve :

  • Une white list des classes que l'on peut utiliser
  • JDO ( si, si ca existe encore :-)) et JPA pour la persistance
  • Coté WAR, la présence de GWT pour un rendu AJAX de l'application
  • d'autres API décrites ici

Un plugin eclipse est aussi disponible

Configuration des ports dans JBOSS AS 4.2.3 GA

Juste un petit billet qui pourra aider - j'espère - les quelques personnes qui doivent installer plusieurs instances de JBOSS AS sur une même machine.

Les ports à paramétrer sont les suivants

PortFichier de configurationValeur par défaut
httpserver\default\deploy\jbossweb-tomcat55.sar\server.xml8080
https server\default\deploy\jbossweb-tomcat55.sar\server.xml8443
ajpserver\default\deploy\jbossweb-tomcat55.sar\server.xml 8009
Web Service server\default\conf\jboss-service.xml 8083
Jms server\default\deploy\jms\uil2-service.xml 8093
Jndi server\default\conf\jboss-service.xml 1099
Rmi server\default\conf\jboss-service.xml 1098
JRMP Server\conf\jboss-service.xml 4444
JRMP Server\conf\jboss-service.xml 4445
Déployeur EJB3 deploy\ejb3.deployer\META-INF\jboss-service.xml 3873

Maintenant, soit vous allez dans tous les fichiers de configuration et vous modifiez les ports, soit vous utilisez le mbean ServiceBindingManager qui est désactivé par défaut .

Vous trouverez en commentaire dans le fichier server/conf/jboss-service.xml la définition suivante:

   <mbean code="org.jboss.services.binding.ServiceBindingManager"
     name="jboss.system:service=ServiceBindingManager">
     <attribute name="ServerName">ports-01</attribute>
     <attribute name="StoreURL">${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml</attribute>
     <attribute name="StoreFactoryClassName">
       org.jboss.services.binding.XMLServicesStoreFactory
     </attribute>
   </mbean>

Dans le fichier exemple fourni par JBOSS, trois configuration types sont fournies en plus de celle par défaut. Personnellement, j'ai fait une copie de ce fichier et l'ai placé dans le répertoire ${jboss.home.url}/server

Deux phénomènes très rares en moins d'une semaine !!

Maven a sorti une nouvelle version 2.10 et Debian Lenny est sorti !

Mulder et Scully, débarquez au plus vite, c'est incroyable!! :-D

Retours sur le DEVOXX au JUG tourangeau

La prochaine rencontre du JUG tourangeau aura lieu le 11 février dans les locaux de SUPINFO.

le sujet abordé sera "les annonces et tendances de la conférence Devoxx".

Pour vous inscrire ça se passe ici !

- page 1 de 3