Discussion :

[hamrouni wassim]

Bonjour à tous, je ne sais pas est ce que je suis dans le bon endroit ou non, bref, je travaille actuellement sur une application j2ee sur eclipse(GMAO) qui est crée avec EJB, (framework Seam),richfaces... dans un serveur d'application JBoss 4.2.2.
Mon chef de projet m'a demandé de faire changer le serveur d'application de JBoss vers Tomcat.
J'ai cherché beaucoup mais jusqu'à ce moment je ne sais est ce que cette action en général est faisable ou non ? Et, si elle est faisable comment ça se fait techniquement.Sachant que je dois aussi éliminer les composants Seam et changer richfaces vers primefaces.
Svp, je veux savoir par quoi je dois commencer ? par éliminer les composants et migrer vers primefaces puis changer le serveur d'application ou bien le contraire ?
C'est très urgent merci d'avance.

[Pill_S]

Alors c'est (normalement) possible, mais... Tomcat n'étant pas un "vrai" container JEE, il risque de te manquer quelques petites choses (les transactions JTA, les impléms JPA, etc...)

Le premier truc, c'est d'identifier toutes les références vers les API propriétaires de JBoss, et de les remplacer par des appels génériques (chercher dans le code toutes les références à des packages genre "org.jboss.as.*").
Ensuite, ajouter à ton war/ear toutes les dépendances manquantes (celles qui étaient fournies par JBoss, déclarées en scope "provided" dans le pom normalement). Tu devras peut-être utiliser un assembly personnalisé pour créer un build spécifique Tomcat.
Ensuite, créer les configurations propres à Tomcat: déclarer tous les objets JNDI utilisés dans un fichier context.xml, etc.
Puis, lancer le bouzin et prier :-) il y aura certainement beaucoup de soucis du genre ClassNotFoundException/NoClassDefFoundError, des incompatibilités de frameworks, etc. et ça, faudra les fixer au fur et à mesure.

Si tu as des tests unitaires (tu devrais!), ça peut largement t'aider en te permettant de tester certaines combinaisons de dépendances sans devoir les charger dans Tomcat. ça ira un peu plus vite... même si ça sera clairement un peu long et chiant :-)

Tu peux aussi décider de partir sur du TomEE, qui est un Tomcat quasi-JEE-compliant, mais je ne l'ai jamais utilisé.

PS: migrer vers/de richfaces, c'est un autre sujet, et peut se faire indifférement avant ou après. Même si je le ferais après... mais c'est une question de préférence personnelle...

[OButterlin]

Ton chef de projet a justifié ce changement ?
J'ai du mal à comprendre pourquoi il veut passer d'un serveur d'applications EE à un conteneur de servlet... ça va imposer pas mal de changements (pas d'EJB) ou alors un assemblage d'options sur le serveur Tomcat...
Il serait certainement plus simple de migrer vers un serveur Wildfly et d'utiliser JSF/Primefaces pour la couche de présentation... mais c'est mon avis

[hamrouni wassim]

Ton chef de projet a justifié ce changement ?
J'ai du mal à comprendre pourquoi il veut passer d'un serveur d'applications EE à un conteneur de servlet... ça va imposer pas mal de changements (pas d'EJB) ou alors un assemblage d'options sur le serveur Tomcat...
Il serait certainement plus simple de migrer vers un serveur Wildfly et d'utiliser JSF/Primefaces pour la couche de présentation... mais c'est mon avis

Merci pour la réponse,pour ta première question, il m'a dit que l'application est lourde,mais je veux savoir comment on fait cette migration techniquement ? et est ce que ce serveur d'application Wildfly va garantir la rapidité de l'exécution de l'application et de quoi il se diffère de JBoss ?

[OButterlin]

Wildfly est le nom des serveurs d'applications JBoss depuis la version 8 donc on reste dans le même monde.
D'un point de vue performance, ça n'a rien à voir avec un JBoss 4 qui était une bouse à démarrer... là, c'est très rapide.
Le serveur est actuellement en version 10, à priori, l'ancienne application devrait avoir très peu de chose à modifier mais bon, ça dépend de la manière de déployer.
Si l'application intègre les jar dont elle a besoin, ça devrait être très facile.
Sinon, il faudra jeter un oeil à la notion de "modules"...