I am running into weird problems when using window scope in IceFaces 3.3. When I put debug statements on constructor and destroy method (using pre-destroy annotation), I am seeing that the same bean is being created and destroyed and re-created when a single user navigates between pages. I checked the access logs on the tomcat server and it shows that the user is using a compatible browser like IE8 and is not opening any new tabs other than navigating between the pages.
What is the lifecycle of a window scoped bean. What triggers a window scope bean to be destroyed?
This behavior does not happen consistently on the same browsers. It happens for some users using IE8 while not others. But most of the cases where the bean is re-created seem to be the cases where the user is behind some kind of proxy. Would the proxy be causing such a behavior? but then again the users session remains valid i.e. the session which keep tracks the name of the user etc., stays the same between pages.
How can this behavior be solved. Is window scope unreliable?
Yes, it's unreliable and perhaps doesn't serve the purpose of window scoping. You need to implement your own custom scope and not the icefaces predefined #{window}. The class org.icefaces.application.WindowScopeManager should give you some hints as to why you are seeing the behavior.
Related
A customer has a number of XPages applications that have a jQuery Mobile user interface for use on iPads. They have been working fine for a long time. There have been no application code changes, but recently users are reporting strange behaviour in the user interface across a number of the applications.
This seems to be related to multi-value fields where JQM shows a long list of values in an overlay. When then selecting a second multi-value field the pop-up box is being displayed but then immediately replaced with the overlay for the first field but without any values.
The Domino server is 8.5.3 FP4 and the administrators tell me there have been no environment and security changes recently.
In addition to the above I am also seeing the following errors occurring :-
16/12/15 15:54: Exception Thrown
com.ibm.xsp.acl.NoAccessSignal
at com.ibm.domino.xsp.module.nsf.NotesContext.checkAccess(NotesContext.java:1631)
at com.ibm.domino.xsp.module.nsf.NotesContext.serverProcessSignedResource(NotesContext.java:975)
at com.ibm.domino.xsp.module.nsf.NotesContext.setSignerSessionRights(NotesContext.java:946)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader$DynamicClassLoader.loadClass(ModuleClassLoader.java:349)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at com.ibm.domino.xsp.module.nsf.ModuleClassLoader.loadClass(ModuleClassLoader.java:171)
at java.lang.ClassLoader.loadClass(ClassLoader.java:626)
at com.ibm.designer.runtime.Application.loadClass(Application.java:708)
at com.ibm.xsp.library.ApplicationFacesClassLoader.loadClass(ApplicationFacesClassLoader.java:54)
at com.ibm.xsp.page.compiled.CompiledPageDriver.getClassForPageName(CompiledPageDriver.java:169)
at com.ibm.xsp.page.compiled.CompiledPageDriver.loadPage(CompiledPageDriver.java:61)
at com.ibm.xsp.application.ViewHandlerExImpl._createViewRoot(ViewHandlerExImpl.java:489)
at com.ibm.xsp.application.ViewHandlerExImpl.createViewRoot(ViewHandlerExImpl.java:557)
at com.ibm.xsp.application.ViewHandlerExImpl.doCreateView(ViewHandlerExImpl.java:141)
at com.ibm.xsp.application.ViewHandlerEx.createView(ViewHandlerEx.java:90)
at com.ibm.xsp.webapp.FacesServlet.serviceView(FacesServlet.java:238)
at com.ibm.xsp.webapp.FacesServletEx.serviceView(FacesServletEx.java:204)
at com.ibm.xsp.webapp.FacesServlet.service(FacesServlet.java:160)
at com.ibm.xsp.webapp.FacesServletEx.service(FacesServletEx.java:138)
at com.ibm.xsp.webapp.DesignerFacesServlet.service(DesignerFacesServlet.java:103)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.invokeServlet(ComponentModule.java:583)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.invokeServlet(NSFComponentModule.java:1281)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$AdapterInvoker.invokeServlet(ComponentModule.java:860)
at com.ibm.designer.runtime.domino.adapter.ComponentModule$ServletInvoker.doService(ComponentModule.java:803)
at com.ibm.designer.runtime.domino.adapter.ComponentModule.doService(ComponentModule.java:572)
at com.ibm.domino.xsp.module.nsf.NSFComponentModule.doService(NSFComponentModule.java:1265)
at com.ibm.domino.xsp.module.nsf.NSFService.doServiceInternal(NSFService.java:658)
at com.ibm.domino.xsp.module.nsf.NSFService.doService(NSFService.java:481)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.doService(LCDEnvironment.java:341)
at com.ibm.designer.runtime.domino.adapter.LCDEnvironment.service(LCDEnvironment.java:297)
at com.ibm.domino.xsp.bridge.http.engine.XspCmdManager.service(XspCmdManager.java:272)
There doesn't seem to be any indication as to which application or XPage these exceptions are related to. And I do not know whether this is related to the issues being seen in the user interface of the various applications.
Can anyone shed any light on this exception or what I should be looking for?
What jumps out are these lines:
at com.ibm.domino.xsp.module.nsf.NotesContext.serverProcessSignedResource(NotesContext.java:975)
at com.ibm.domino.xsp.module.nsf.NotesContext.setSignerSessionRights(NotesContext.java:946)
I don't know which application is causing the problem, but it looks it may be having a problem assigning signer rights. It may be worth checking for multiple signers of design elements.
The com.ibm.xsp.acl.NoAccessSignal exception is thrown when an anonymous user tries to access a protected XPages resource. So this exception has nothing to do with the strange behaviour that you are experiencing.
Here is my scenario. I have a component which searches some records and while searching, those records are marked locked. I am using JSF-2 and primefaces. My MBean is ViewScoped. Now i have a requirement, while closing the browser, the lock on those records need to be released. I was searching and my best bet appears to be #PostDestroy. So can someone help, whether using PostDestroy is correct approach. Some of the threads on StackOverFlow suggest, PostDestroy doesn't get called on browser close events. I I am not able to find much on PostDestroy. Can someone provide pointers on this approach?
Thanks,
Ben
Your #ViewScoped Bean does not know if the user is closing the browser. For the Bean it does not even matter if the client is a browser or some other HTTP-client.
The lifetime of a #ViewScoped Bean ends normally if your application sends a postback to the next view (see How and when is a view scope bean destroyed in JSF for an exact answer).
You can try to detect a closing browser with the JavaScript window.onunload event but I would not recommend that. Some browsers fire this event on browser close, others not, some fire it on reload etc. (see DOM Window unload event, is it reliable? for more details).
The #PreDestroy annotated Method (not #PostDestroy btw.) may also not be called immediately in some cases. You can only rely that it will be called on a session timeout. Which may be a long time for locking records...
You could release the locked records after a shorter period on your own using some kind of scheduler but I'd recommend to switch to optimistic locking (Don't lock and check if data has changed before you write).
I'm working with a Liferay portlet with JSF2 and Primefaces.
A lot of my Backing Beans are SessionScoped, as they are keeping info needed from multiple pages of the same portlet, and I want them to keep this info for the whole session, so I can't turn them to ViewScoped.
This way, the user has to log-out and log-in to reset the Backing Beans, and this is the supposed behavior I wanted. But I'd like to reset them when the user navigates to another portal page. So, my question is, what is the most convenient way to do this ?
Is there some Event I could catch when changing the page, and call some custom reset function on the Portlet?
Maybe some default setting on the portlet that will automatically reset the beans (no custom reset functions) ?
Any other Ideas ?
thanx!
I've got a little problem I'd like to solve.
I use Apache Myface 2 with Tomahawk and Trinidad.
Trinidad delivers its Dialog Framework to create Modal Dialogs...
My problem is that after the Dialog is closed, I want to refresh (re-render) the caller page.
As a solution I handle the ReturnListener, update the data of my bean, and send an ExternalContext.redirect to reload my page... but my ViewScoped bean is destroyed and a new one is create !
It is quite logical, but is there a way to reload a page from a Viewscoped bean without sending a redirect (that will destroy the bean...) ?
Is the only solution to use partial redering ?
To have it work I changed the scope to Session, but it's uggly in my case.
Thanks for your answers.
If you want to stick to view scope then yes only ppr can be of help, its not actually hard to set partialTrigger on the top level element which will refresh everything inside.
On the other had if you are ok to go with session or application scope i think you already are able to do that.
When I open two browsers and enter details parallely, the values are getting mixed. The values in one browser are populated in the other browser... We are using JSF framework and the managed beans are in session scope (having them in request scope is not possible in our case)... In a nutshell, the values are shared across the browsers... How to avoid this? Any clue?
If you "open two browsers" means you open two windows of same browser then everything is correct - you can get just one session per browser (for firefox there is plug-in which allow to avoid this limitation).
But if you use really two different browsers than in this case seams you save all data in application scope or you have a problem with you container.
You need to put the bean in request or view scope instead. Storing request/view based data in a session scoped bean is a bad idea, as you've encountered yourself.
I think the view scope would help a lot, given the fact that you mentioned that the request scope is "not possible" (it actually is, it only requires preloading the right data so that JSF can take the right actions accordingly).