2010-03-18 5 views
0

Nous procédons actuellement à la mise à niveau vers WebSphere 7.0 sur Windows 2008 R2. Nos applications fonctionnent actuellement sur WebSphere 6.1 sous Windows 2003.Composant html JSF sur WebSphere 7.0

Nous utilisons des contrôles personnalisés que nous avons écrits en utilisant JSF 1.1 dans nos applications. Nos contrôles semblent rendre et d'interagir très bien, mais chaque fois que nous utilisons un composant JSF HTML comme:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> 
... 
<h:graphicImage url="#{MenuBean.bannerImagePath}" /> 

Nous obtenons l'erreur suivante:

com.ibm.ws.jsp.JspCoreException: Unable to convert string '#{MenuBean.bannerImagePath}' to class javax.el.ValueExpression for attribute url: java.lang.IllegalArgumentException: Property Editor not registered with the PropertyEditorManager 
com.ibm.ws.jsp.JspCoreException: Unable to convert string '#{MenuBean.bannerImagePath}' to class javax.el.ValueExpression for attribute url: java.lang.IllegalArgumentException: Property Editor not registered with the PropertyEditorManager 
    at org.apache.jasper.runtime.JspRuntimeLibrary.getValueFromPropertyEditorManager(JspRuntimeLibrary.java:939) 
    at com.ibm._jsp._dashboard._jspx_meth_h_graphicImage_0(_dashboard.java:136) 
    at com.ibm._jsp._dashboard._jspx_meth_f_view_0(_dashboard.java:436) 
    at com.ibm._jsp._dashboard._jspService(_dashboard.java:109) 
    at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:98) 
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) 
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1583) 
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1523) 

J'ai trouvé un article sur le site Web d'IBM donnant une correctif possible: http://www-01.ibm.com/support/docview.wss?uid=swg21318801

Toutefois, j'ai supprimé les fichiers jar spécifiés et je reçois toujours le message d'erreur. Encore une fois, nos contrôles personnalisés semblent fonctionner correctement sous JSF 1.2 de WebSphere 7.

Merci pour toute aide que vous pouvez fournir. Mike

Liste des WEB-INF \ lib

  • activation.jar
  • commons-BeanUtils-1.8.0.jar
  • commons-collections-3.2.1.jar
  • communes -dbcp-1.2.2.jar
  • commons-digesteur 1.8.1.jar
  • commons-fileupload-1.2.1.jar
  • commons-io-1.4.jar
  • commons-logging-1.1.1.jar
  • commons-pool-1.4.jar
  • concurrent.jar
  • DIB-2.0.3.jar
  • ibatis -2.3.4.726.jar
  • -ifc 3.1.0.jar
  • imgipt-3.0.0.7.jar
  • ironeyesql.jar
  • iText-2.1.5.jar
  • JasperReports-3.5.0.jar
  • jaxen-full.jar
  • jcommon-1.0.12.jar
  • jdom.jar
  • jdt-compilateur 3.1.1.jar
  • jfreechart- 1.0.9.jar
  • localisation-3.1.0.jar
  • log4j-1.2.15.jar
  • mail.jar
  • mflutil-3.1.0.jar
  • mmwfoundation-3.1.0.jar
  • RapidSpellWeb.jar
  • saxpath.jar
  • Stedmans.dict
  • tcr-3.1.0.jar
  • xalan.jar
  • xercesImpl-2.4.0.jar
  • xml-apis.jar
+2

Il doit toujours y avoir une API JSF 1.1/impl errant n'importe où dans le chemin de classe. Pour commencer, pouvez-vous lister les bibliothèques dans votre '/ WEB-INF/lib' ici? – BalusC

+0

Votre annonce a l'air bien. Pas de JSF ni de pots javaee. Que diriez-vous de '/ jre/lib' et'/jre/lib/ext' et d'autres chemins externes couverts par le classpath? Si ce n'est pas le cas, il reste WebSphere. Mais il devrait en fait déjà être livré avec JSF 1.2 hors de la boîte. – BalusC

Répondre

0

Après recompiler contre JSF 1.2, la reconstruction des fichiers de configuration , et la mise à jour des fichiers tld dans le dossier WEB-INF, je suis heureux de signaler que notre problème est résolu. Pas exactement sûr qui a réglé le problème. Merci pour votre temps.

Mike

+0

Il devrait en effet y avoir ** aucun ** fichiers TLD spécifiques à JSF dans '/ WEB-INF'. Cela peut aussi être l'une des causes de ce problème. Il faut * jamais * extraire le fichier JAR taglib pour mettre les fichiers TLD libres dans le classpath, et encore moins le définir dans le fichier 'web.xml'. – BalusC

Questions connexes