Quelles sont les risques de passage de jdk6/jboss6 vers jdk7/jboss7 pour une application Java EE ?

Bonjour !
Nous avons une application Java EE développée avec jdk6 et déployée sous le serveur d'application Jboss 6.
Notre entreprise aimerait que nous basculions sur jdk7 et jboss 7
Dans l'environnement de test nous avons régénérer le .war avec jdk7 et nous l'avons deployé sous jboss 7.
A l'exécution nous avons obtenu une erreur qui demandait d'encadrer nos objets par la balise

Code:

---

<h:form></h:form>

---

J'aimerais savoir quelles sont les conséquences pour notre application lorsqu'on passe de jdk6/jboss6 vers jdk7/jboss7 ?

Merci pour vos aides !

Les risques sont multiples, difficile de répondre sans connaître l'application.
Ceci dit, passer d'une version 6 obsolète à une version 7 obsolète... pas trop d'intérêt...
Tans qu'à faire ce boulot de vérification, autant passer sur la version 8 de java et un serveur Wildfly...

Bonne chance en tout cas

Merci OButterlin pour ta réaction rapide
Nous allons songé à ta proposition de passage vers jdk8/Wildfly (je pense à Wildfly 9).
La question des risques reste posée. Est-ce qu'il n'y aurait pas des fonctions depréciées ? ...

Merci

C'est la version 10 de Wildfly qui est la dernière... ça va vite ;)

Il y a des "défauts" qui peuvent changer, comme par exemple la version jsf, hibernate, etc...
En ce qui concerne jsf and Cie, par défaut WildFly est plutôt orienté vers l'injection CDI (plutôt que JSF), il faudra peut-être revoir certains fichiers de paramétrage.
Comme je n'ai jamais utilisé la version 6, je ne sais pas trop de quoi tu pars...

Personnellement, j'utilise un JBoss7 et je n'ai pas encore réussi à faire tourner correctement les applications avec Wildfly 9, je vais tester la v10, on verra...

Avez-vous essayé Windup qui normalement permet de voir les soucis d'une application pour une migration ?
Après il existe aussi des commandes de migration pour les différents sous-systèmes pour faciliter le passage d'HornetQ à Artemis et JBossWeb à Undertow (entre autres).
Par exemple: https://github.com/wildfly/wildfly/b...Operation.java à appeler depuis la CLI

Le principal souci pour moi est lié au custom valve utilisé pour différencier nos 3 types d'authentifications... et là... c'est mal barré :aie:
Pour le reste, ça semble fonctionner pas trop mal.

Il 'suffit' de la transformer en Handler Undertow (ce qui est loin d'être la mort) par contre la limite est que ton handler est définit par rapport à une location (de tête) donc c'est pas déployable via ton war.

Je vais regarder ce mécanisme, merci pour la piste ;)

Y a quelques informations sur les valves "standard" de Tomcat/JBossWeb qui sont celles que l'on migre via la commande migrate (attention uniquement les valves globales, aka pas définies pour une application uniquement): https://docs.jboss.org/author/displa...AS7+to+WildFly
Après pour les handlers Undertow: http://undertow.io/undertow-docs/und...ler-guide.html
Tu peux aussi regarder celles qui sont dans Undertow, moi j'avais écrit toute une application en handlers pour "remplacer" les servlets: https://github.com/devoxx2014-webper...dertow_handler mais c'est un peu vieux