Discussion :

[JacNar6]

Bonjour!

Il est question pour moi de développer de nouvelles applications à déployer sur un serveur en production, qui n'est rien d'autre que la version 4.2 de JBoss. Pour le besoin de productivité je préfère utiliser PrimeFaces 5 qui entre de plus en plus dans mes habitutes.

J'ai donc pensé modifier la version de JSF présente dans la version 4.2.3.GA de JBoss, en remplaçant les jar jsf-api et jsf-impl par les versions 2.1.7. Une fois ceci fait j'ai et une simple application Primefaces déployé, l'accès à l'application déployé génère l'erreur ci dessous

ava.lang.IllegalStateException: Tentative non autorisée de définition de ViewHandler après la restitution d’une réponse.
at com.sun.faces.application.ApplicationImpl.setViewHandler(ApplicationImpl.java:564)
at org.ajax4jsf.event.InitPhaseListener.beforePhase(InitPhaseListener.java:92)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
at java.lang.Thread.run(Thread.java:724)

Quelqu'un comprendrait-il cette erreur et saurait-il comment le résoudre ?

Cordialement!

[JacNar6]

J'ai moi même un début de solution.

Occupe erreur n'est générée pour une version non polluée de JBoss-4.2.3.GA. J'utilise sur mon poste local une copie exacte de la configuration de JBoss en production, et ce dernier contient dans son lib des jar supplémentaires.

Après contrôle minutieux, je constate que celui qui fait mon malheur est: richfaces-impl.jar (car tout ce passe bien lorsque je l'enlève bien, il n'est pas utilisé par mon appli primefaces de test). Bien sûr il n'est pas queestion de le supprimer, car il est utilisé par des applications en exploitations. Je vais donc voir du côté des version de richfaces.

En continuant de creuser, vos réactions et suggestions seraient les bienvenues .

[OButterlin]

Pourquoi ne pas mettre les jars dans /WEB-INF/lib de ton application ?
Là, tu risques de "contrarier" sévèrement des applications existantes sur le serveur... il risque d'y avoir des dépendances vers d'autres bibliothèques (comme le parser)

[JacNar6]

Pourquoi ne pas mettre les jars dans /WEB-INF/lib de ton application ?

Est ce à dire que je peux déployer mon application avec sa propre version de JSF ? Ce serait vraiment bon à savoir!

Là, tu risques de "contrarier" sévèrement des applications existantes sur le serveur... il risque d'y avoir des dépendances vers d'autres bibliothèques (comme le parser)

J'avoue là que j'avance avec un peu de foi, espérant que ce ne soit pas le cas, sinon bien venu jquery , car l'équipe en place ne garde pas de très bon souvenir de richfaces .

En attendant la réponse à ma question ci-dessus, voici un lien utile qui a résolu l'erreur mentionnée plus haut; mais j'ai maintenant l'erreur ci-dessous

com.sun.facelets.tag.TagException: /index.xhtml @7,17 <h:head> Tag Library supports namespace: http://java.sun.com/jsf/html, but no tag was defined for name: head
at com.sun.facelets.compiler.CompilationManager.pushTag(CompilationManager.java:193)
at com.sun.facelets.compiler.SAXCompiler$CompilationHandler.startElement(SAXCompiler.java:194)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:195)
at com.sun.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:232)
at com.sun.facelets.compiler.Compiler.compile(Compiler.java:105)
at com.sun.facelets.impl.DefaultFaceletFactory.createFacelet(DefaultFaceletFactory.java:218)
at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:149)
at com.sun.facelets.impl.DefaultFaceletFactory.getFacelet(DefaultFaceletFactory.java:100)
at com.sun.facelets.FaceletViewHandler.buildView(FaceletViewHandler.java:517)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:567)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:100)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:176)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:722)

Le fichier index concerné est le suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html">
    <h:head>
        <title>Facelet Title</title>
    </h:head>
    <h:body>
        Hello from Facelets
        <br />
        <h:link outcome="welcomePrimefaces" value="Primefaces welcome page" />
    </h:body>
</html>

Apparemment les tags ne sont pas reconnus.

[OButterlin]

Je viens de faire un test avec jsf2 sur un serveur jboss-4.2.3, bon, ce n'est pas aussi simple que ça.
Visiblement, il tient bien compte des lib dans l'application mais elle ne sont pas compatibles avec le listener d'intégration du serveur...
Je n'ai pas trop le temps de pousser actuellement mais à l'occasion, j'essayerai...

[EDIT]
En regardant la spécification, il semble que la version jsf 2.0 soit compatible avec un conteneur servlet 2.5 mais les version 2.1 et 2.2 nécessitent la version 3.0 du conteneur de servlet...
Du coup, ça paraît un peu compromis...

[tchize_]

Faire tourner la dernière version de primefaces sur jboss 4.2: tu aime te faire fouetter avec les orties fraîches toi
Avoir dans ce serveur jboss 4.2 d'autres apps que tu ne peux pas perturber: tu aime rajouter des clous sur tes orties toi

Il serait vraisemblablement plus simple de faire tourner un deuxième serveur Jboss pour ton application.

[JacNar6]

Je viens de faire un test avec jsf2 sur un serveur jboss-4.2.3, bon, ce n'est pas aussi simple que ça.
Visiblement, il tient bien compte des lib dans l'application mais elle ne sont pas compatibles avec le listener d'intégration du serveur...
Je n'ai pas trop le temps de pousser actuellement mais à l'occasion, j'essayerai...

[EDIT]
En regardant la spécification, il semble que la version jsf 2.0 soit compatible avec un conteneur servlet 2.5 mais les version 2.1 et 2.2 nécessitent la version 3.0 du conteneur de servlet...
Du coup, ça paraît un peu compromis...

Je me suis justement rendu compte de tout ça; très sincèrement si tu trouves une config qui fasse l'affaire, cela m'intéresserais beaucoup (je préfère vivement utiliser un seul outil pour mes pages que de mélanger des quantités de framework).

[JacNar6]

Faire tourner la dernière version de primefaces sur jboss 4.2: tu aime te faire fouetter avec les orties fraîches toi
Avoir dans ce serveur jboss 4.2 d'autres apps que tu ne peux pas perturber: tu aime rajouter des clous sur tes orties toi

Tu veux tuer mon espoir!

Il serait vraisemblablement plus simple de faire tourner un deuxième serveur Jboss pour ton application.

Si j'avais le choix c'est ce que je ferai tchize_; la totalité des applications de la structure est administré via un portail unique, faire tourner un deuxième serveur JBoss signifie isoler mon application du portail (pas bien vu par le service en charge de l'exploitation). Pour une fois tu n'es pas mon libérateur toi

[OButterlin]

Si tu regardes ici, tu constateras que pour primefaces 5.0 c'est mort... et la version 4.0 dépend également de la version 3.0 de servlet...

A part un développement en jsf 1.2 avec une ancienne version de primefaces (ou RichFaces), ça risque d'être très très compliqué...

[JacNar6]

Si tu regardes ici, tu constateras que pour primefaces 5.0 c'est mort... et la version 4.0 dépend également de la version 3.0 de servlet...

A part un développement en jsf 1.2 avec une ancienne version de primefaces (ou RichFaces), ça risque d'être très très compliqué...

Merci pour ton aide OButterlin. C'est dur de devoir retourner en arrière, mais c'est aussi cela apparemment les réalités de l'informatique dans le monde des entreprises.

Comme disent certain, "à défaut de ce qu'on veut et de ce qu'on aime, on se contente de ce qu'on a" fin de citation.

[OButterlin]

Comme disent certain, "à défaut de ce qu'on veut et de ce qu'on aime, on se contente de ce qu'on a" fin de citation.

Pour être honnête, il faut bien reconnaitre que ce que veut l'un n'est pas forcément ce que veut l'autre. L'arbitrage provoquera forcément de la frustration

Sinon, pour ton problème, as-tu pensé à faire l'inverse : porter tes anciennes applications sur jboss 7.1 ?

[tchize_]

ou wildfly 8 ?

En tout cas, j'ai eu personnellement beaucoup plus facile à porter des application de jboss 4 vers 8 que de 4 vers 6, le 8 est vraiment bien foutu pour ce qui est de l'isolation des applications et de la gestion des conflits entre les applications et les librairies système

[JacNar6]

Pour être honnête, il faut bien reconnaitre que ce que veut l'un n'est pas forcément ce que veut l'autre. L'arbitrage provoquera forcément de la frustration

Sinon, pour ton problème, as-tu pensé à faire l'inverse : porter tes anciennes applications sur jboss 7.1 ?

Une migration futur est déjà prévu, mais c'est pas pour tout de suite (apparemment on attend qu'il n'y ait plus rien à développer ). L'urgence est plutôt du côté des nouvelles applications à développer.

Je pense que le moment venu je relancerais tchize_, pour un retour d'expérience

[OButterlin]

ou wildfly 8 ?

En tout cas, j'ai eu personnellement beaucoup plus facile à porter des application de jboss 4 vers 8 que de 4 vers 6, le 8 est vraiment bien foutu pour ce qui est de l'isolation des applications et de la gestion des conflits entre les applications et les librairies système

Effectivement, il y a aussi la version 8, je l'oublie toujours celle-là comme elle n'est pas clairement identifiée sur leur portail de téléchargement

Ceci dit, la 7.1.1 est tout aussi bien foutue pour l'isolation, mais dans les 2 cas, il va falloir apprendre à paramétrer certains liens externes au projet via les "modules".
Pour ça, n'oublie pas la possibilité dans le /META-INF/MANIFEST.MF

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Manifest-Version: 1.0
Dependencies: nom.module1, nom.module2

[JacNar6]

Je clic sur résolu pour signifier que j'attendrai patiemment la migration. C'es déjà bon de savoir que cela peux se faire sans toucher les codes sources dans la mesure où l'isolation des applications et de la gestion des conflits entre les applications est possible dans les nouvelles version de jboss.

[tchize_]

disons que c'était possible mais vachement plus compliqué dans les anciennes