I was wondering how to preserve an application when the user leave the application completly by going to another site (for example when the user logs into the application and then goes to nytimes.com and then comes back to the application some components go missing). To preserve the application on a refresh you can use the #PreserveOnRefresh annotation, but this does not preserve the application when you leave it. The header, menu and footer are disappearing. These three components are have their own class and are only declared in the main ui. Each view (or page) has its own class (which sit between the menu and the footer). Everything works fine until the user leaves the webpage and comes back the header, menu, and footer disapear So my question is how to preserve my vaadin application when the user leaves it and comes back?
Well, there could be problem with serialization and deserialization from session. Make sure you have implemented Serialization interface for your own classes.
Have you tried to repaint the missing components? They should be set to setImmediate(false) during repaintRequest.
Anyway, ordinary Vaadin application works without problem after returning back from other url. So good luck.
To solve this situation you can add a listener to the navigator which will get the uri to the page you are going to and check your permissions. If you do not have permission it will keep you on the same page and give you a notification saying that you are not allowed to go to this page. If they are allowed you will proceed to direct them to that page.
What components are missing when you go back to the application? Vaadin applicaction lives as long as web session. If I go to nytimes.com and then go back before the web session ends, the Vaadin application will survive (if it has #PreserveOnRefresh) or will be renewed
Related
I've ran into a strange problem using Vaadin. In my application I need to dynamicly push new data to the table viewed by the user. I've done some reading and it seems that I could achive just that with Vaadins' #Push feature.
But as soon as I've added the #Push annotation to my UI class everything stopped working. What I mean by this is I'm getting that message when accessing the UI
Session Expired. Take note of any unsaved data, and click here or press ESC key to continue.
clicking on the message just refreshes the whole page.
I'm using Vaadin 8.0.6 and vaadingSpring 2.0.1, as well as Spring Boot 1.5.3
Does anyone know how to solve this?
Oh, I almost forgot. I've used this code as an example
https://github.com/peholmst/vaadin4spring/blob/master/samples/push-sample/src/main/java/org/vaadin/spring/samples/push/PushUI.java
I found Push (with Spring) hard to configure. It was my fault, for sure, but I finally decided to drop it in favor of this simple extension which implements a client-based polling: https://vaadin.com/directory#!addon/timerextension-add-on
This issue may have to do with a very specific Domino version (see below), so I start with a few technical details:
Server in question is a virtualized Windows 2008 R2 64bit machine. Domino release is
IBM Domino (r) Server (64 Bit) (Release 9.0.1FP4 HF70 for Windows/64)
The latest JVM security patch (9.0.1.4 dated 20150724) is installed.
I may be wrong but I feel that the issue started after we installed the latest patches (FP4 HF70 and JVM):
On an Xpage I have a very simple "Refresh" type button just triggering a partial refresh on an xp:panel (id="pnMainContainer") surrounding the bigger part of my page. Amongst other components there is a tabbed panel inside pnMainContainer. This is set to open with the first of three tabs upon loading the page.
Assuming that I have the third tab open, usually if I click the Refresh button tab #3 stays open, and its contents are freshed as expected.
Sometimes however, after I left the page open for a several minutes (can't really say how long, maybe somewhere around half an hour), the refresh obviously is returning to its initial state, showing the first tab instead of the one that was open before, and emptying all editable fields that were filled before.
When that happens I see the following warning appear on the console:
HTTP JVM: WARNING: CLFAD####W: State data not available for /myPage
because no control tree was found in the cache.
I am aware of this post here: Xpages document changing document mode?, and although I don't use Xagents in my application I tried setting my page's viewState property to nostate. This apparently didn't help solve the problem.
One more detail that might be helpful is the fact that the page in question makes use of a managedBean bound to the viewScope.
Any ideas what could be causing this, and - moreover - how to change this behaviour?
Update 2015-09-10: following #Paul's suggestions below I set my application's session timeout to 120 minutes last night (xsp.session.timeout=120). This morning I tried again: loaded the page in question then let it sit there for approx. 45 minutes. After that time hit my partial refresh button. Result: page is reloaded to its initial state, and server console is showing the same warning as yesterday.
For completeness sake here's the entire contant of my application's xsp.properties as it is at the moment:
xsp.error.page.default=true
xsp.library.depends=com.ibm.xsp.extlib.library
xsp.resources.aggregate=true
xsp.theme=oneuiv3.0.2
xsp.session.timeout=120
xsp.application.timeout=120
xsp.persistence.mode=basic
Is there probably something in there that would be causing this behaviour?
Some more details: did some more testing and found the following details:
with the above mentioned xsp.properties caching appears to be stable for quite a while as long as I let the pages just sit there
as soon as I make any kind of adjustments somewehere on my page or in related codes (SSJS libs, managed beans, or the page itself) cache needs to be rebuilt as the state of my page is lost (even after a few seconds). It doesn't matter at all whether "Build automatically" is turned on in Designer or not
Tried setting page persistence from xsp.persistence.mode=basic to xsp.persistence.mode=file. This results in a "java.io.NotSerializableException" as soon as I open tab #3 which makes use of internal properties of a managedBean that is registered at a viewScope level
Built a very simple app on the same server with just a few partial refesh buttons: result is that page state is never lost for pages from this test application
As long as the cache is lost only when I update design I don't really care. But I'm afraid that this might escalate if many users are starting to access the pages.
Anything else I could do to improve performance?
viewState="nostate" basically means don't store the component tree or scoped variables for this page server-side. That's why you use it for XAgents, which will never be partially refreshed.
The key data is:
1) How quickly the XPages session is set to timeout. Once that times out, you'll lose state data. I don't think keepSessionAlive control helps here.
2) Whether other tabs are being opened in the browser. There are other XPages properties that determine the number of pages stored in memory / disk. The maximum is stored for the whole browser session and, once you hit the maximum, the earliest is dropped from memory, hence the same message (and the other reason for setting nostate on XAgents.
It sounds like the first is the cause. Note that XPages session timeout and http timeout are separate timeouts. The first is when the state data for the current session is removed and is application-specific (because each XPages app has a separate runtime JVM), the second when a subsequent request to the browser will prompt for authentication.
So I have a website and I'm putting an Applet on it, and every so often, I update and re-upload that Applet. However, I cannot seem to view the changes I made to the Applet only. I am able to update and re-upload the index.html file, and I can view the change immediately, but It takes a day for me to be able to see the update I made to the Applet.
The odd thing is that my friends are able to see the change I made to the Applet immediately, so I know that the upload did work.
Yes, I have tried clearing my cache and restarting my browser, but that does not seem to work.
Open the Java Console & flush the class cache, then refresh the page.
For more reliable and controllable updates, deploy the applet using Java Web Start. For a better experience generally, deploy the app. as a JFrame using JWS.
I've figured a weird issue with Wicket 1.5.x. All of the sudden, wicket started to append a number that increases to every url which looks like mydomain.com/home?1. For every Bookmarkable link I click, wicket sends a redirect to the browser increasing that number. Same happens for when trying to clean the url and calling mydomain.com/home I end up with another redirect and an increased number.
What's even worse is that on Google App Engine the version number when clicking a link increase by the factor of two which also seems to cause issues with submitting forms which simply do.. well.. nothing!?
I've tried to play around with setVersioned(false)/true and setStatelessHint(false)/true without any result. What could that be, how to get rid of it and how can it influence my app not working on GAE?
thanks a bunch
Alex
EDIT:
It looks like wicket is always incrementing the version for my page as my base page is stateful (shows user's name if any in a model). But nothing changes on the site yet clicking i.e. my Bookmarkable Link to my home site increases it's page id with every click so if the user clicks 10x times on the home link his history is polluted with 10 entries of the exactly same page as nothing has changed.. this doesn't make any sense at all so I am curious how to fix that without loosing being stateful!?
The number represents the version of the page. It appears when the page is stateful (thus the server must track its state).
It takes a little more than set the stateless hint to make a page stateless. You must avoid any component that holds state on the server side, and use stateless alternatives (StatelessForm instead of Form, StatelessLink instead of Link).
I answered this question with an example of a stateless page: Is it difficult to make a mainly stateless web application with Wicket?
There is a Jira ticket: setVersioned(false) should force single Page Version about this issue. The question has also been discussed in the mailing list. Expected complications: Page Reload on Submit of non-versioned Page
For my particular project, I'm using Facelets (1.1.14), MyFaces (1.2.3), and Spring Web Flow (2.0.3). My IDE is JDeveloper 10.1.3.3. My browser is IE6 (work requirement).
Okay...ran into a very weird issue today. Normally, when I'm using Facelets, I can make whatever changes I want to my xhtml file, refresh my browser window, and see the changes immediately. I've got Facelets development set to true, and Facelets refresh period set to 1.
Up to this afternoon, I've had no problem with Facelets refreshes on this project. However, just this afternoon, I starting finding that changes to css styles and classes did not appear when I refreshed the page. Then I started seeing similar issues with other page elements. In some cases the changes never appear. At other times, I can refresh the page after a little while has passed and the changes have been reflected.
What happened to my Facelets page refreshes? It's like they've gone all sticky. I'm used to immediate changes on page refresh without complications. Has anyone run into this before? Any solutions or suggestions?
EDIT
The issue has something to do with Spring Web Flow. One of my pages is pure Facelets, and it's reflecting changes on refresh immediately. My other xhtml pages are invoked as view states in my flow definitions, and show the symptoms described above. Still, they were working fine just a day or two ago...
EDIT
Ok, I've been able to isolate the symptom, but I still don't know its cause.
It seems that whenever I have a facelets xhtml file that is rendered as a view-state of a flow and has an h:form element, then I get odd behavior when I make changes to the JSF elements on my page and refresh my browser. This includes not showing changes in their styles or style classes.
Changes to regular HTML elements (like changing the style of an input element) seem to work fine. Changing the h:form to a regular HTML form allow for immediate changes on page refresh, even on JSF elements. When I view the page when I'm not executing a flow (just using Facelets), then I never encounter any problems, even when using an h:form.
Please tell me someone has encountered this before, and has some solution. Anyone?
If you have entry of facelets.REFRESH_PERIOD -1 in your web.xml , this is causing the problem. Just cross check it by removing this entry.
I'm not sure if this applies to Web Flow, but I do know that with Spring MVC, you have an option of having your controller implement the LastModified interface, which allows Spring to send the browser the "Last-Modified" HTTP header.
Servlets typically don't set this HTTP header value, causing browsers to request a new copy of the files each time, however, if the "Last-Modified" header is set, browsers know not to retrieve the contents of a URL if it hasn't been modified since the page was last retrieved.
I suspect your Web Flow "controller" (pardon my abuse of terminology, I'm not familiar with Web Flow) is setting the "Last-Modified" header, while your regular Facelets page is not.
For what it's worth, I think setting Last-Modified is generally a good idea, unless your page is dynamic.