Type API variabele-resolver is verouderd na JSF 1.1. Gebruik in plaats daarvan el-resolver

We hebben onlangs een upgrade uitgevoerd van WebSphere Portal v6.1 naar v7.0 en we hebben nu JSF 1.2 beschikbaar. Het maken van een nieuw Portlet-project in Rad 8 maakt een faces-config.xml met het volgende item


    com.ibm.faces.application.DevelopmentStateManager
    com.ibm.faces.portlet.PortletVariableResolver

En dan klaagt: Type API variabele-resolver is gedeprecieerd na JSF 1.1. Gebruik in plaats daarvan el-resolver.

Helaas kon ik geen antwoord vinden op de IBM-pagina's die el-resolver moest gebruiken.

Bewerk:

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

=> Resolver: [email protected]

Een item toevoegen in faces-config

com.sun.faces.el.FacesCompositeELResolver

Met of zonder het verwijderen van de variabele-resolver leidt tot:

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 met IBM opende ...

6
toegevoegd de auteur Brad, de bron
Waarschuwingsbericht van RAD: Klasse javax.el.ELResolver moet concreet (niet abstract) zijn.
toegevoegd de auteur Stefan, de bron
We gebruiken Spring en er is org.springframework.web.jsf.DelegatingVariableResolver. Het werkt goed. Misschien probeert u een afhankelijkheid toe te voegen voor deze resolver? Zet het als org.springframework.web.jsf.DelegatingVariableResolver
toegevoegd de auteur JMelnik, de bron

2 antwoord

IBM's antwoord op de PMR:

V - Wat kunnen de gevolgen zijn van het negeren van de waarschuwing?

Ans - Gebruiker kan nog steeds variabele resolver gebruiken, de functionaliteit wordt niet beïnvloed. [Deze tag wordt behouden voor compatibiliteit met eerdere versies]

V - Waarom gebruikt de gegenereerde faces-config.xml nog steeds de gedeprecieerde methode?

Ans - We gebruiken variabele resolver om de portletvariabelen op te lossen, wat goed zou werken, zelfs met JSF 1.2

V - Zal er een el-resolver zijn voor portlets?

Ans - Er komt een el-resolver voor portlets. Het wordt geleverd in JSF portlet bridge 2.0, die wordt verzonden als een update voor WAS. Het bevindt zich momenteel in de planningsfase, dus ik kan je geen precieze versie geven waar dit in zal worden gevonden.

1
toegevoegd

Ik haat het om het te zeggen, maar als we het hebben over een asynchrone webapplicatie, dan ben je dood in het water.

JSF 1.2 introduceerde een "bekende bug" (ik hield altijd van die zin) is de FaceletsRenderer -klasse die voorkomt dat je asynchroon JSF-componenten rendert (omdat alle aynchronousiteit in JSF een nep gebruikt FacesContext ; niet een functionele die kan worden gebruikt voor rendering). Je hebt JEE6-vriendelijke JSF 2.1 daarvoor nodig , anders heb je een andere oplossing nodig, zoals @ D1e in zijn/haar opmerking aangeeft. Veel geluk voor uw organisatie.

0
toegevoegd
Ik ben in de war, hoe asynchrone webapps gerelateerd kunnen zijn aan de vraag. Vooral omdat de stacktrace FacesServlet.init bevat die wordt uitgevoerd vóór elke aanvraagverwerking.
toegevoegd de auteur A.H., de bron
Ik gebruik helemaal geen Facelets.
toegevoegd de auteur Stefan, de bron