jsf - javax.faces.application.ViewExpiredException:दृश्य को पुनर्स्थापित नहीं किया जा सका




jsf-2 logout (9)

मैंने कंटेनर-प्रबंधित सुरक्षा के साथ सरल आवेदन लिखा है। समस्या यह है कि जब मैं लॉग इन करता हूं और एक और पेज खोलता हूं जिस पर मैं लॉगआउट करता हूं, तो मैं पहले पेज पर वापस आ जाता हूं और मैं किसी लिंक पर क्लिक करता हूं या पेज रीफ्रेश करता हूं, मुझे यह अपवाद मिलता है। मुझे लगता है कि यह सामान्य है (या शायद नहीं :)) क्योंकि मैंने लॉग आउट किया और सत्र नष्ट हो गया। उदाहरण के लिए index.xhtml या login.xhtml के लिए उपयोगकर्ता को रीडायरेक्ट करने के लिए मुझे क्या करना चाहिए और उसे उस त्रुटि पृष्ठ / संदेश को देखने से बचाएं?

दूसरे शब्दों में लॉग आउट करने के बाद मैं अन्य पृष्ठों को स्वचालित रूप से इंडेक्स / लॉगिन पेज पर रीडायरेक्ट कैसे कर सकता हूं?

यह रहा:

javax.faces.application.ViewExpiredException: viewId:/index.xhtml - View /index.xhtml could not be restored.
    at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:212)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at filter.HttpHttpsFilter.doFilter(HttpHttpsFilter.java:66)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
    at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
    at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
    at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
    at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
    at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
    at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
    at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
    at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
    at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
    at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
    at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
    at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
    at java.lang.Thread.run(Thread.java:619)

Answers

क्या आपने नीचे अपने web.xml लाइन जोड़ने की कोशिश की है?

<context-param>
   <param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
   <param-value>true</param-value>
</context-param>

जब मुझे इस मुद्दे का सामना करना पड़ा तो मैंने इसे बहुत प्रभावी पाया।


सबसे पहले आपको क्या करना है, web.xml बदलने से पहले यह सुनिश्चित करना है कि आपका प्रबंधित बीन implements Serializable :

@ManagedBean
@ViewScoped
public class Login implements Serializable {
}

विशेष रूप से यदि आप MyFaces का उपयोग करते हैं


मैं web.xml पर निम्न कॉन्फ़िगरेशन जोड़ता हूं और इसे हल किया गया है।

<context-param>
    <param-name>com.sun.faces.numberOfViewsInSession</param-name>
    <param-value>500</param-value>
</context-param>
<context-param>
    <param-name>com.sun.faces.numberOfLogicalViews</param-name>
    <param-value>500</param-value>
</context-param>

मुझे यह त्रुटि मिल रही थी: javax.faces.application.ViewExpiredException। जब मैं विभिन्न अनुरोधों का उपयोग करता हूं, तो मुझे सर्वर को पुनरारंभ करने के बाद भी वही JsessionId होता है। तो यह ब्राउज़र कैश के कारण है। बस ब्राउज़र बंद करें और कोशिश करें, यह काम करेगा।


कृपया इस लाइन को अपने web.xml में जोड़ें यह मेरे लिए काम करता है

<context-param>
        <param-name>org.ajax4jsf.handleViewExpiredOnClient</param-name> 
        <param-value>true</param-value>     
    </context-param>

आप अपने स्वयं के कस्टम AjaxExceptionHandler या प्राइमफ़ेस-एक्सटेंशन का उपयोग करते हैं

अपने चेहरे-config.xml अद्यतन करें

...
<factory>
  <exception-handler-factory>org.primefaces.extensions.component.ajaxerrorhandler.AjaxExceptionHandlerFactory</exception-handler-factory>
</factory>
...

अपने जेएसएफ पेज में निम्नलिखित कोड जोड़ें

...
<pe:ajaxErrorHandler />
...

मैं स्वयं इस समस्या में भाग गया और महसूस किया कि यह एक फ़िल्टर के दुष्प्रभाव के कारण था जिसे मैंने बनाया था जो कि एप्लायंस पर सभी अनुरोधों को फ़िल्टर कर रहा था। जैसे ही मैंने केवल कुछ अनुरोधों को चुनने के लिए फ़िल्टर को संशोधित किया, यह समस्या नहीं हुई। अपने आवेदन में ऐसे फ़िल्टरों की जांच करना शायद अच्छा होगा और देखें कि वे कैसे व्यवहार करते हैं।


परिचय

जब भी javax.faces.STATE_SAVING_METHOD server (डिफ़ॉल्ट) पर सेट होता है तो javax.faces.STATE_SAVING_METHOD फेंक दिया जाएगा और javax.faces.STATE_SAVING_METHOD <h:form> साथ <h:commandLink> , <h:commandButton> साथ एक HTTP POST अनुरोध भेजता है <f:ajax> , जबकि संबंधित दृश्य स्थिति अब सत्र में उपलब्ध नहीं है।

दृश्य स्थिति को एक छिपे हुए इनपुट फ़ील्ड javax.faces.ViewState के मान के रूप में पहचाना जाता है। <h:form> दृश्य दृश्य। server सहेजने वाली राज्य बचत विधि के साथ, इसमें केवल दृश्य स्थिति आईडी होती है जो सत्र में क्रमबद्ध दृश्य स्थिति का संदर्भ देती है। इसलिए, जब किसी कारण से सत्र समाप्त हो जाता है (या तो सर्वर या क्लाइंट साइड में समय समाप्त हो जाता है, या सत्र कुकी अब ब्राउज़र में किसी कारण से नहीं रखी जाती है, या सर्वर में HttpSession#invalidate() को कॉल HttpSession#invalidate() , या किसी सर्वर विशिष्ट के कारण WildFly में ज्ञात सत्र कुकीज़ के साथ बग), फिर सीरियलाइज्ड व्यू WildFly सत्र में अब उपलब्ध नहीं है और एंडुसर को यह अपवाद मिलेगा। सत्र के काम को समझने के लिए, servlets कैसे काम करते हैं यह भी देखें ? इंस्टेंटेशन, सत्र, साझा चर और मल्टीथ्रेडिंग

जेएसएफ सत्र में स्टोर किए जाने वाले विचारों की एक सीमा भी है। जब सीमा हिट हो जाती है, तो कम से कम हाल ही में उपयोग किया जाने वाला दृश्य समाप्त हो जाएगा। Com.sun.faces.numberOfViewsInSession बनाम com.sun.faces.numberOfLogicalViews भी देखें।

client को स्टेट सेविंग विधि सेट करने के साथ, javax.faces.ViewState छिपे हुए इनपुट फ़ील्ड में पूरे सीरियलाइज्ड व्यू javax.faces.ViewState बजाय शामिल है, इसलिए ViewExpiredException को सत्र समाप्त होने पर ViewExpiredException नहीं मिलेगा। हालांकि यह क्लस्टर पर्यावरण पर अभी भी हो सकता है ("त्रुटि: मैक सत्यापित नहीं किया गया है" लक्षण है और / या जब क्लाइंट साइड स्टेटस पर कार्यान्वयन-विशिष्ट टाइमआउट कॉन्फ़िगर किया गया है और / या जब सर्वर पुनरारंभ के दौरान एईएस कुंजी को फिर से उत्पन्न करता है , क्लस्टर पर्यावरण में ViewExpiredException प्राप्त करना भी देखें, जबकि राज्य की बचत विधि क्लाइंट पर सेट की गई है और उपयोगकर्ता सत्र मान्य है कि इसे कैसे हल किया जाए।

समाधान के बावजूद, सुनिश्चित करें कि आप enableRestoreView11Compatibility उपयोग नहीं करते हैं। यह मूल दृश्य स्थिति को पुनर्स्थापित नहीं करता है। यह मूल रूप से दृश्य और सभी संबंधित दृश्यों को स्क्रैच से स्कैन किए गए बीन्स को दोबारा शुरू करता है और इस प्रकार सभी मूल डेटा (राज्य) को खो देता है। चूंकि एप्लिकेशन एक भ्रमित तरीके से व्यवहार करेगा ("अरे, मेरे इनपुट मान कहां हैं .. ??"), यह उपयोगकर्ता अनुभव के लिए बहुत बुरा है। स्टेटलेस दृश्यों का बेहतर उपयोग करें या <o:enableRestorableView> इसके बजाय आप इसे सभी दृश्यों के बजाय केवल एक विशिष्ट दृश्य पर प्रबंधित कर सकते हैं।

क्यों जेएसएफ को दृश्य स्थिति को बचाने की जरूरत है, इस जवाब पर जाएं: जेएसएफ सर्वर पर यूआई घटकों की स्थिति क्यों बचाता है?

पृष्ठ नेविगेशन पर ViewExpiredException से बचें

ViewExpiredException से बचने के लिए, जब राज्य की बचत server सेट की जाती server , तो लॉगआउट के बाद वापस नेविगेट करना, केवल लॉगआउट के बाद POST अनुरोध को पुनर्निर्देशित करना पर्याप्त नहीं है। आपको ब्राउज़र को डायनामिक जेएसएफ पृष्ठों को कैश करने के लिए निर्देश देने की भी आवश्यकता नहीं है , अन्यथा जब आप उस पर जीईटी अनुरोध भेजते हैं तो ब्राउज़र से ताज़ा एक का अनुरोध करने के बजाय ब्राउज़र उन्हें कैश से दिखा सकता है (उदाहरण के लिए बैक बटन)।

कैश किए गए पृष्ठ के javax.faces.ViewState छिपे हुए फ़ील्ड में एक दृश्य स्थिति आईडी मान हो सकता है जो वर्तमान सत्र में अब मान्य नहीं है। यदि आप पेज-टू-पेज नेविगेशन के लिए जीईटी (नियमित लिंक / बटन) के बजाय POST (कमांड लिंक / बटन) का उपयोग कर (एबी) हैं, और कैश किए गए पृष्ठ पर ऐसे कमांड लिंक / बटन पर क्लिक करें, तो यह बदलेगा एक ViewExpiredException साथ विफल।

जेएसएफ 2.0 में लॉगआउट के बाद रीडायरेक्ट को फायर करने के लिए, या तो <redirect /> <navigation-case> को प्रश्न में ( <redirect /> प्रश्न में जोड़ें (यदि कोई हो) जोड़ें, या outcome मूल्य में ?faces-redirect=true जोड़ें।

<h:commandButton value="Logout" action="logout?faces-redirect=true" />

या

public String logout() {
    // ...
    return "index?faces-redirect=true";
}

गतिशील जेएसएफ पृष्ठों को कैश न करने के लिए ब्राउज़र को निर्देश देने के लिए, एक Filter बनाएं जो FacesServlet के सर्वलेट नाम पर मैप किया गया है और ब्राउज़र कैश को अक्षम करने के लिए आवश्यक प्रतिक्रिया शीर्षलेख जोड़ता है। उदाहरण के लिए

@WebFilter(servletNames={"Faces Servlet"}) // Must match <servlet-name> of your FacesServlet.
public class NoCacheFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        HttpServletResponse res = (HttpServletResponse) response;

        if (!req.getRequestURI().startsWith(req.getContextPath() + ResourceHandler.RESOURCE_IDENTIFIER)) { // Skip JSF resources (CSS/JS/Images/etc)
            res.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
            res.setHeader("Pragma", "no-cache"); // HTTP 1.0.
            res.setDateHeader("Expires", 0); // Proxies.
        }

        chain.doFilter(request, response);
    }

    // ...
}

पेज रीफ्रेश पर ViewExpiredException से बचें

जब ViewExpiredException server सेट किया जाता server , तो वर्तमान पृष्ठ को रीफ्रेश करते समय ViewExpiredException से बचने के लिए, आपको केवल यह सुनिश्चित करने की आवश्यकता नहीं है कि आप विशेष रूप से जीईटी (नियमित लिंक / बटन) द्वारा पेज-टू-पेज नेविगेशन कर रहे हैं, लेकिन आपको भी आवश्यकता है सुनिश्चित करें कि आप फॉर्म जमा करने के लिए विशेष रूप से AJAX का उपयोग कर रहे हैं। यदि आप किसी भी तरह से फॉर्म को सिंक्रनाइज़ (गैर-AJAX) सबमिट कर रहे हैं, तो आप या तो दृश्य को बेकार (बाद में अनुभाग देखें), या पोस्ट के बाद रीडायरेक्ट भेजने के लिए (पिछले अनुभाग देखें)।

पृष्ठ रीफ्रेश पर ViewExpiredException होने पर डिफ़ॉल्ट कॉन्फ़िगरेशन में एक बहुत ही दुर्लभ मामला है। यह तभी हो सकता है जब सत्र में जेएसएफ स्टोर की संख्या को सीमित कर देगा। इसलिए, यह तब होगा जब आपने मैन्युअल रूप से उस सीमा के रास्ते को बहुत कम सेट किया है, या आप लगातार पृष्ठभूमि में नए विचार बना रहे हैं (उदाहरण के लिए बुरी तरह से लागू मतदान द्वारा)। Com.sun.faces.numberOfViewsInSession बनाम com.sun.faces.numberOfLogicalViews भी देखें। एक और कारण रनटाइम क्लासपाथ में डुप्लिकेट जेएसएफ पुस्तकालयों को एक-दूसरे से विवाद कर रहा है। जेएसएफ स्थापित करने की सही प्रक्रिया हमारे जेएसएफ विकी पेज में उल्लिखित है।

ViewExpiredException को संभालना

जब आप किसी अन्य टैब / विंडो में लॉग आउट होने पर कुछ ब्राउज़र टैब / विंडो में पहले से खोले गए किसी मनमानी पृष्ठ पर पोस्ट कार्रवाई के बाद एक अपरिहार्य ViewExpiredException को संभालना चाहते हैं, तो आप के लिए एक error-page निर्दिष्ट करना चाहते हैं कि web.xml जो "आपका सत्र समाप्त हो गया है" पृष्ठ पर जाता है। उदाहरण के लिए

<error-page>
    <exception-type>javax.faces.application.ViewExpiredException</exception-type>
    <location>/WEB-INF/errorpages/expired.xhtml</location>
</error-page>

अगर आप वास्तव में घर या लॉगिन पेज पर रीडायरेक्ट करना चाहते हैं तो त्रुटि पृष्ठ में मेटा रीफ्रेश हेडर आवश्यक होने पर उपयोग करें।

<!DOCTYPE html>
<html lang="en">
    <head>
        <title>Session expired</title>
        <meta http-equiv="refresh" content="0;url=#{request.contextPath}/login.xhtml" />
    </head>
    <body>
        <h1>Session expired</h1>
        <h3>You will be redirected to login page</h3>
        <p><a href="#{request.contextPath}/login.xhtml">Click here if redirect didn't work or when you're impatient</a>.</p>
    </body>
</html>

( content में 0 रीडायरेक्ट से पहले सेकंड की मात्रा का प्रतिनिधित्व करता है, 0 इस प्रकार इसका मतलब है "तुरंत रीडायरेक्ट करें", आप ब्राउज़र का उपयोग 3 सेकंड को रीडायरेक्ट के साथ करने के लिए कर सकते हैं)

ध्यान दें कि AJAX अनुरोधों के दौरान अपवादों को संभालने के लिए एक विशेष ExceptionHandler आवश्यकता होती है। जेएसएफ / प्राइमफेसेस AJAX अनुरोध पर सत्र टाइमआउट और ViewExpiredException हैंडलिंग भी देखें। आप OmniFaces FullAjaxExceptionHandler शोकेस पेज पर एक लाइव उदाहरण पा सकते हैं (इसमें गैर-AJAX अनुरोध भी शामिल हैं)।

यह भी ध्यान रखें कि आपके "सामान्य" त्रुटि पृष्ठ को <exception-type> के बजाय <error-code> पर मैप किया जाना चाहिए जैसे कि java.lang.Exception या java.lang.Throwable , अन्यथा ServletException में लिपटे सभी अपवाद जैसे कि ViewExpiredException अभी भी सामान्य त्रुटि पृष्ठ में समाप्त होगा। Java.lang में दिखाए गए ViewExpiredException को भी देखें। Web.xml में धोने योग्य त्रुटि-पृष्ठ

<error-page>
    <error-code>500</error-code>
    <location>/WEB-INF/errorpages/general.xhtml</location>
</error-page>

स्टेटलेस विचार

स्टेटलेस मोड में जेएसएफ विचारों को चलाने के लिए एक बिल्कुल अलग विकल्प है। इस प्रकार जेएसएफ राज्य के कुछ भी नहीं बचाए जाएंगे और विचार कभी समाप्त नहीं होंगे, लेकिन केवल हर अनुरोध पर खरोंच से पुनर्निर्मित किया जाएगा। आप <f:view> की transient विशेषता को true करके सेट करके स्टेटलेस दृश्य चालू कर सकते हैं:

<f:view transient="true">

</f:view>

इस तरह javax.faces.ViewState छिपे हुए क्षेत्र को Mojarra में "stateless" का एक निश्चित मान मिलेगा (इस बिंदु पर MyFaces की जांच नहीं की है)। ध्यान दें कि यह सुविधा Mojarra 2.1.19 और 2.2.0 में introduced गई थी और पुराने संस्करणों में उपलब्ध नहीं है।

नतीजा यह है कि आप दृश्य स्कॉप्ड बीन्स का अब और उपयोग नहीं कर सकते हैं। वे अब अनुरोधित बीन्स के अनुरोध की तरह व्यवहार करेंगे। नुकसान में से एक यह है कि आपको छुपे हुए इनपुट और / या ढीले अनुरोध पैरामीटर के साथ झुकाव करके खुद को राज्य को ट्रैक करना होगा। मुख्य रूप से उन फॉर्मों को इनपुट फ़ील्ड के साथ rendered किया rendered जो rendered , readonly या disabled गुणों के साथ हैं जो AJAX ईवेंट द्वारा नियंत्रित होते हैं।

ध्यान दें कि <f:view> को पूरे दृश्य में अद्वितीय होने की आवश्यकता नहीं है और / या केवल मास्टर टेम्पलेट में रहना आवश्यक है। यह टेम्पलेट क्लाइंट में फिर से घूमने और घोंसला करने के लिए पूरी तरह से कानूनी है। यह मूल रूप से माता-पिता <f:view> "विस्तारित करता है"। मास्टर टेम्पलेट में जैसे:

<f:view contentType="text/html">
    <ui:insert name="content" />
</f:view>

और टेम्पलेट क्लाइंट में:

<ui:define name="content">
    <f:view transient="true">
        <h:form>...</h:form>
    </f:view>
</f:view>

आप <f:view> को <c:if> सशर्त बनाने के लिए भी लपेट सकते हैं। ध्यान दें कि यह न केवल उपरोक्त उदाहरणों में, <h:form> जैसे नेस्टेड सामग्री पर, संपूर्ण दृश्य पर लागू होगा।

यह भी देखें

कंक्रीट समस्या से असंबंधित , शुद्ध पृष्ठ-से-पृष्ठ नेविगेशन के लिए HTTP पोस्ट का उपयोग करना बहुत उपयोगकर्ता / एसईओ अनुकूल नहीं है। जेएसएफ 2.0 में आपको <h:link> या <h:button> <h:commandXxx> सादा वेनिला पेज-टू-पेज नेविगेशन के लिए वास्तव में पसंद करना चाहिए।

तो उदाहरण के बजाय

<h:form id="menu">
    <h:commandLink value="Foo" action="foo?faces-redirect=true" />
    <h:commandLink value="Bar" action="bar?faces-redirect=true" />
    <h:commandLink value="Baz" action="baz?faces-redirect=true" />
</h:form>

बेहतर करो

<h:link value="Foo" outcome="foo" />
<h:link value="Bar" outcome="bar" />
<h:link value="Baz" outcome="baz" />

यह भी देखें


नीचे दी गई प्रक्रिया जेबॉस एएस 7.2+ , जेबॉस ईएपी 6.1+ , और जेबॉस वाइल्डफली 8+ पर लागू होती है और मानती है कि आपके पास सर्वर स्थापना और कॉन्फ़िगरेशन पर पूर्ण नियंत्रण है। यह सर्वर-व्यापी डिफ़ॉल्ट जेएसएफ संस्करण को अपग्रेड करता है:

  • व्यक्तिगत Mojarra API और impl फ़ाइलों को डाउनलोड करें (और इस प्रकार एकल javax.faces.jar फ़ाइल नहीं)। वर्तमान नवीनतम 2.1.x संस्करण 2.1.2 9 है और वर्तमान नवीनतम 2.2.x संस्करण 2.2.14 है। आइए मान लें कि आप 2.2.x पर अपग्रेड करना चाहते हैं। आप उन्हें अपने मैवेन रिपोजिटरी से व्यक्तिगत रूप से डाउनलोड कर सकते हैं:
  • सुनिश्चित करें कि जेबॉस बंद हो गया है।
  • जेएसएफ एपीआई /modules/system/layers/base/javax/faces/api/main :
    • पुराने जेएआर फ़ाइल को हटाएं या बैकअप लें (इसे उसी फ़ोल्डर में न रखें, यहां तक ​​कि नाम भी नहीं बदला गया है!)।
    • वहां jsf-api-2.2.14.jar फ़ाइल jsf-api-2.2.14.jar
    • <resource-root> module.xml <resource-root path="jsf-api-2.2.14.jar"/> में नई फ़ाइल नाम निर्दिष्ट करने के लिए module.xml फ़ाइल खोलें और <resource-root> संपादित करें
  • जेएसएफ इत्यादि /modules/system/layers/base/com/sun/jsf-impl/main अद्यतन करें:
    • पुराने जेएआर फ़ाइल को हटाएं या बैकअप लें (इसे उसी फ़ोल्डर में न रखें, यहां तक ​​कि नाम भी नहीं बदला गया है!)।
    • वहां jsf-impl-2.2.14.jar फ़ाइल jsf-impl-2.2.14.jar
    • <resource-root> module.xml <resource-root path="jsf-impl-2.2.14.jar"/> में नई फ़ाइल नाम निर्दिष्ट करने के लिए module.xml फ़ाइल खोलें और <resource-root> संपादित करें
  • स्वच्छता जेबॉस कैश / कार्य डेटा यह सुनिश्चित करने के लिए कि वहां पर लटकाए गए पिछले तैनाती से जेएआर की कोई पुरानी प्रतिलिपि नहीं है जो संभावित रूप से केवल नए जारों से टकराएगी:
    • /standalone/data की सभी सामग्री को /standalone/data (कस्टम डेटा फ़ोल्डर्स को छोड़कर, अपलोड की गई फाइलों वाले फ़ोल्डर, बेशक)
    • /standalone/deployments की सभी सामग्री /standalone/deployments
    • /standalone/tmp की सभी सामग्री /standalone/tmp
  • जेबॉस शुरू करो। अब इसे सभी तैनाती के लिए नए जेएसएफ संस्करण का उपयोग करना चाहिए।

जेबॉस एएस 7.0 / 7.1 और जेबॉस ईएपी 6.0 पर एक ही प्रक्रिया लागू होती है, आपको केवल /modules/system/layers/base/* बजाय /modules/* ब्राउज़ करना होगा, और आपको वहां पुरानी। .index फ़ाइल को स्पष्ट रूप से हटाने की आवश्यकता है , यदि कोई है (जेबॉस एक स्वामित्व करेगा)। साथ ही, यदि API फ़ोल्डर में module.xml <module name="com.sun.jsf-impl"/> <dependencies> अंदर याद <dependencies> , तो आपको इसे मैन्युअल रूप से जोड़ना होगा।

महत्वपूर्ण नोट यह है कि 2.2.7 से पुराने पुराने org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.faces.flow.builder.FlowDefinition निम्नलिखित अपवाद के साथ तैनाती के दौरान एएस / ईएपी में विफल हो जाएंगे org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.faces.flow.builder.FlowDefinition । इसके बाद आप मूल रूप से 2 विकल्प हैं: Mojarra 2.1.x पर डाउनग्रेड करें, या कम से कम 2.2.7 या नए पर अपग्रेड करें।

यदि आप Mojarra 2.3 में अपग्रेड करना चाहते हैं, जो javax.faces.jar पर अब 2-जेएआर संस्करण प्रदान नहीं करता है, तो आपको इस प्रक्रिया के अनुसार javax.faces.jar फ़ाइल के आधार पर 2-जेएआर संस्करण मैन्युअल रूप से बनाना होगा। : WildFly पर जेएसएफ (javax.faces.jar) के एक जार संस्करण को कैसे स्थापित करें





jsf jsf-2 logout viewexpiredexception