Il resolver variabile di tipo API è deprecato dopo JSF 1.1. Utilizzare invece el-resolver

Abbiamo recentemente effettuato l'aggiornamento da WebSphere Portal v6.1 alla v7.0 e nel processo ora è disponibile JSF 1.2. Creazione di un nuovo progetto portlet nel Rad 8 crea un faces-config.xml con la seguente voceIl resolver variabile di tipo API è deprecato dopo JSF 1.1. Utilizzare invece el-resolver

<application> 
    <state-manager>com.ibm.faces.application.DevelopmentStateManager</state-manager> 
    <variable-resolver>com.ibm.faces.portlet.PortletVariableResolver</variable-resolver> 
</application>

E poi si lamenta: Type API variabile resolver è deprecato dopo JSF 1.1. Utilizzare invece el-resolver.

Purtroppo non sono riuscito a trovare una risposta nelle pagine IBM che el-resolver usasse.

Edit:

System.out.println("Resolver: " + PortalUtil.getFacesContext().getApplication().getELResolver());

=> Resolver: [email protected]

Aggiunta di una voce in faces-config

<el-resolver>com.sun.faces.el.FacesCompositeELResolver</el-resolver>

Con o senza rimuovere il resolver variabile porta a:

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory 
    at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:270) 
    at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164) 
    at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:358) 
    ... 89 more

PMR con IBM aperto ...

fonte

2011-10-27 Stefan

Non è di aiuto? http://download.oracle.com/docs/cd/E17802_01/products/products/jsp/2.1/docs/jsp-2_1-pfd2/javax/el/ELResolver.html – Brad

Messaggio di avviso da RAD: Classe javax.el. ELResolver deve essere concreto (non astratto). – Stefan

Usiamo Spring, e c'è org.springframework.web.jsf.DelegatingVariableResolver. Funziona bene.Forse prova ad aggiungere una dipendenza per questo risolutore? Metti come org.springframework.web.jsf.DelegatingVariableResolver – JMelnik

IBMs risposta al PMR:

D - Quali possono essere le conseguenze di ignorare l'avvertimento?

Ans: l'utente può ancora utilizzare il risolutore di variabili, la funzionalità non verrà modificata. [Questo tag verrà mantenuto per la retrocompatibilità]

Q - Perché il file faces-config.xml generato utilizza ancora il metodo deprecato?

Ans - Stiamo utilizzando resolver variabile per risolvere le variabili portlet, che avrebbe funzionato bene anche con JSF 1.2

D - Ci sarà o c'è un El-resolver per portlet?

Ans - Ci sarà un resolver el per i portlet. Sarà fornito in JSF portlet bridge 2.0 che verrà inviato come aggiornamento a WAS. E 'attualmente in fase di pianificazione quindi non posso darti una versione precisa in cui si troverà.

fonte

2011-12-05 19:36:23 Stefan

Odio dirlo, ma se stiamo parlando di un'applicazione web asincrona, allora sei morto nell'acqua.

JSF 1.2 introdotto un "noto bug" (Ho sempre amato quella frase) è la classe FaceletsRenderer che ti impedisce di rendere in modo asincrono componenti JSF (perché tutti aynchronousity in JSF utilizza un falsificateFacesContext, non uno funzionale che può essere utilizzato per il rendering). Hai bisogno di JSF 2.1 JEE6 compatibile per questo, altrimenti avrai bisogno di una soluzione diversa del tutto, come indicato da @D1e nel suo commento. Buona fortuna per la tua organizzazione.

fonte

2011-11-05 15:39:19 IAmYourFaja

Sono confuso, come le applicazioni web asincrone potrebbero essere correlate alla domanda. Soprattutto perché lo stacktrace contiene 'FacesServlet.init' che viene eseguito prima di qualsiasi elaborazione di richiesta. –

Hm non sta usando affatto i Facelet. – Stefan

Il resolver variabile di tipo API è deprecato dopo JSF 1.1. Utilizzare invece el-resolver

risposta

Problemi correlati