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




jsf-2 logout (7)

मैंने कंटेनर-प्रबंधित सुरक्षा के साथ सरल आवेदन लिखा है। समस्या यह है कि जब मैं लॉग इन करता हूं और एक और पेज खोलता हूं जिस पर मैं लॉगआउट करता हूं, तो मैं पहले पेज पर वापस आ जाता हूं और मैं किसी लिंक पर क्लिक करता हूं या पेज रीफ्रेश करता हूं, मुझे यह अपवाद मिलता है। मुझे लगता है कि यह सामान्य है (या शायद नहीं :)) क्योंकि मैंने लॉग आउट किया और सत्र नष्ट हो गया। उदाहरण के लिए 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)

परिचय

जब भी 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" />

यह भी देखें


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

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

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

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

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

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

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

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


जब हमारा पृष्ठ एक्स के लिए निष्क्रिय होता है तो दृश्य समाप्त हो जाएगा और javax.faces.application.ViewExpiredException को एक समाधान होने से रोकने के लिए कस्टमव्यूहैंडलर बनाना है जो ViewHandler को बढ़ाता है और पुनर्स्थापित ओवरराइड दृश्य विधि को अन्य सभी तरीकों को सौंप दिया जा रहा है माता-पिता

import java.io.IOException;
import javax.faces.FacesException;
import javax.faces.application.ViewHandler;
import javax.faces.component.UIViewRoot;
import javax.faces.context.FacesContext;
import javax.servlet.http.HttpServletRequest;

public class CustomViewHandler extends ViewHandler {
    private ViewHandler parent;

    public CustomViewHandler(ViewHandler parent) {
        //System.out.println("CustomViewHandler.CustomViewHandler():Parent View Handler:"+parent.getClass());
        this.parent = parent;
    }

    @Override 
    public UIViewRoot restoreView(FacesContext facesContext, String viewId) {
    /**
     * {@link javax.faces.application.ViewExpiredException}. This happens only  when we try to logout from timed out pages.
     */
        UIViewRoot root = null;
        root = parent.restoreView(facesContext, viewId);
        if(root == null) {
            root = createView(facesContext, viewId);
        }
        return root;
    }

    @Override
    public Locale calculateLocale(FacesContext facesContext) {
        return parent.calculateLocale(facesContext);
    }

    @Override
    public String calculateRenderKitId(FacesContext facesContext) {
        String renderKitId = parent.calculateRenderKitId(facesContext);
        //System.out.println("CustomViewHandler.calculateRenderKitId():RenderKitId: "+renderKitId);
        return renderKitId;
    }

    @Override
    public UIViewRoot createView(FacesContext facesContext, String viewId) {
        return parent.createView(facesContext, viewId);
    }

    @Override
    public String getActionURL(FacesContext facesContext, String actionId) {
        return parent.getActionURL(facesContext, actionId);
    }

    @Override
    public String getResourceURL(FacesContext facesContext, String resId) {
        return parent.getResourceURL(facesContext, resId);
    }

    @Override
    public void renderView(FacesContext facesContext, UIViewRoot viewId) throws IOException, FacesException {
        parent.renderView(facesContext, viewId);
    }

    @Override
    public void writeState(FacesContext facesContext) throws IOException {
        parent.writeState(facesContext);
    }

    public ViewHandler getParent() {
        return parent;
    }

}   

फिर आपको इसे अपने चेहरे-config.xml में जोड़ना होगा

<application>
    <view-handler>com.demo.CustomViewHandler</view-handler>
</application>

नीचे दिए गए लिंक पर मूल उत्तर के लिए धन्यवाद: http://www.gregbugaj.com/?p=164


मैं 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>

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


Richfaces में मल्टीपार्ट रूपों से बचें:

<h:form enctype="multipart/form-data">
    <a4j:poll id="poll" interval="10000"/>
</h:form>

यदि आप Richfaces का उपयोग कर रहे हैं, तो मुझे पता चला है कि मल्टीपार्ट फॉर्मों के अंदर AJAX अनुरोध प्रत्येक अनुरोध पर एक नया व्यू आईडी लौटाते हैं।

डीबग कैसे करें:

प्रत्येक AJAX अनुरोध पर एक व्यू आईडी लौटा दी जाती है, यह तब तक ठीक है जब तक व्यू आईडी हमेशा समान होती है। यदि आपको प्रत्येक अनुरोध पर एक नया व्यू आईडी मिलता है, तो एक समस्या है और इसे ठीक किया जाना चाहिए।