Hi Henrik,
good hint!
Finally I copied your source code directly in my project. This compiles and works fine with my default Java 1.5!
Thanks, Thorsten
••••••••••
Eclipse 3.5.1 • Vaadin 6.2.2 • Vaadin Eclipse Integration 1.2.0 • Java 1.5
Windows 2000 • IE7 • Tomcat 6.0
HI Henrik,
Just downloaded your 0.0.3 version of SessionGuard.
Line 157 in SessionGuard#setTimeoutWarningHTML. I think it should read
if(timeoutWarningHTML != null) {
...
...
}I’m getting a NPE when I set the value :-/
-=bootlaces=-
Well, isn’t that an embarrassing bug. Good that I haven’t promoted that to Stable from Beta 
Thanks for trying, noticing and reporting. As a prize, here’s a fixed version 0.0.4:
http://vaadin.com/directory#addon/71
!
I try to use Session Guard with portlet V2.0, ApplicationPortlet2 and PortletApplicationContext2 and I got an exception:
Caused by: java.lang.ClassCastException: class com.github.wolfie.sessionguard.SessionGuard must be used in a com.vaadin.terminal.gwt.server.
WebApplicationContext, currently trying to be used in a com.vaadin.terminal.gwt.server.PortletApplicationContext2.
at com.github.wolfie.sessionguard.SessionGuard.attach(SessionGuard.java:72)
at com.vaadin.ui.AbstractComponent.setParent(AbstractComponent.java:569)
at com.vaadin.ui.AbstractComponentContainer.addComponent(AbstractComponentContainer.java:207)
at com.vaadin.ui.AbstractOrderedLayout.addComponent(AbstractOrderedLayout.java:68)
at com.spribo.vaadin.ui.SpriboVerticalLayout.addComponent(SpriboVerticalLayout.java:50001)
at com.spribo.vaadin.portlet.target.zone.ui.TargetView.addComponent(TargetView.java:50001)
at com.vaadin.ui.Panel.addComponent(Panel.java:280)
at com.vaadin.ui.Window.addComponent(Window.java:215)
at com.qoslabs.phronesis.hermeneutics.PortletApplication.init(PortletApplication.java:294)
at com.spribo.vaadin.portlet.SpriboApplication.init(SpriboApplication.java:50001)
at com.spribo.vaadin.portlet.target.zone.TargetZonePortlet.init(TargetZonePortlet.java:50001)
at com.vaadin.Application.start(Application.java:545)
at com.qoslabs.phronesis.hermeneutics.PortletApplication.start(PortletApplication.java:50001)
at com.spribo.vaadin.portlet.SpriboApplication.start(SpriboApplication.java:50001)
at com.spribo.vaadin.portlet.target.zone.TargetZonePortlet.start(TargetZonePortlet.java:50001)
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.startApplication(AbstractApplicationPortlet.java:750)
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.handleRequest(AbstractApplicationPortlet.java:399)
... 137 more
Checking code I see next lines:
final ApplicationContext context = application.getContext();
if (context instanceof WebApplicationContext) {
final WebApplicationContext webContext = (WebApplicationContext) context;
sessionTimeout = webContext.getHttpSession().getMaxInactiveInterval();
} else {
throw new ClassCastException(getClass() + " must be used in a "
+ WebApplicationContext.class.getName()
+ ", currently trying to be used in a "
+ context.getClass().getName() + ".");
}
Are there any special reason to don’t support PortletApplicationContext2?
Hm, I’ve made this decision a good time ago, so I’ve forgotten the particulars. But, IIRC, the functionality depends it on being a true application context, so that the component can reliably get a correct session length.
I’ve never used portlets myself, so I haven’t really tested whether my assumptions are true or not, but I can imagine it might wreak havoc if wrong session info is retrieved.
Be how it may, I wanted to make sure that the component isn’t used in murky waters, that might cause weird behavior. If you feel adventurous, feel free to get the source code, remove that check, recompile the widget and see what happens. I’d be interested to hear the results.
Hi Henrik
I changed Session Guard code to use PortletApplicationContext2 and I add it to one of my portlets, I saw the warning message, but after session time out I saw a [quote]
Communication problem
[/quote] message instead of [quote]
Session expired
[/quote] message.
I’m using Vaadin 6.3.4 with Liferay 5.2.3, and I’m not sure who is displaying the [quote]
Session expired
[/quote] message that I saw in your on live demo. Any ideas?
Thanks
Hi Henrik
I was looking for different messages at Vaadin and I found where messages are generated:
Servlet manage in a better way SessionExpiredException than portlet, so I think my issue was at Vaadin code.
Thanks
Hi,
I would also be interested in this feature in portlet context.
Have you succeeded in integrate this feature in this context ?
If it is ok, i can try it. It could be interesting to make this component compliant.
If you want, i also can contribute for it.
Regards,
Pierre
Sorry, I have no experiences in using portlets, so I have no guarantees that whether this works in portlets or not.
You’re free to try. The addon is released under the Apache 2.0 license, so you’re free to modify it. Since the sources are up on GitHub, feel free to fork the project and give me a pull request. I have no idea whether I get messaged from the request, so it’s best that you reply to this thread afterwards, just to make sure.
OK Henrik,
I’ll have a look.
I tell you more soon.
Thank you for this Add-on Henrik!
We (no me personally) have put it on BlackBeltFactory.com, in production.
But it seems not to work (I still see the red box “Session Expired”).
We probably do something wrong.
SessionGuard sessionGuard = new SessionGuard();
sessionGuard.setKeepalive(true); // true = keeps the session alive
window.addComponent(sessionGuard);
I don’t think that we have recompiled the widgetset. Do we need to do that?
Many thanks.
John.
Holy moly that’s awesome to hear!
…uh-oh.
The code above looked very ok. But since the widget does have a client-side part (unfortunately 
), the widgetset needs to be recompiled. Try that, and if it still doesn’t work, please report back with the version of Vaadin you’re using, and I probably need to know which server you’re using.
Hope it’s just a matter of a recompilation of the widgetset.
Hi Henrik,
We redeployed a version with the recompiled wigetset and it does not work for us. We still have the red “Session Expired” box after 30 minutes of inactivity.
We use Tomcat 6, and Vaadin 6.5.4.
You can check at BlackBeltFactory.com
Any idea how to debug this?
Many thanks.
John.
I have no direct hunch as to why it shouldn’t work. I developed this with Tomcat 6 (changing this, I feel, should be the only reason why it would break) but with an earlier version of Vaadin.
Just a sanity check: Is the component ‘visible’ at all times? Since this is a client-side component, you need to have the component present in all views you have. So, it doesn’t suffice to have it added to a layout once, and then be done with it.
I’ll look into this tomorrow (Friday) and I’ll report back as soon as I get something out of this. Sorry for your troubles 
Running on the Tomcat and Vaadin versions you named, my test application doesn’t fail
One thing you could check is to make sure that the following code (try it from your Application’s init()-method) results to the equal to the timeout in minutes you have configured for Tomcat:
((WebApplicationContext) getContext()).getHttpSession().getMaxInactiveInterval() / 60If it does, I’m stumped. If it doesn’t, however, that’s a possible problem. If you have not defined the servlet’s timeout in the web.xml, you should try to do that, by adding the following lines underneath the closing tag :
<session-config>
<session-timeout>5</session-timeout>
</session-config>How do you check that?
Yes, it does.
Well, the most reliable way is to go to the view where the session guarding fails, and check the DOM structure in the browser for an element having a sessionguard class name. FireBug works perfectly for this, but Chrome has something similar built-in.
But basically what you want to do is that you make sure that the layout you add the SessionGuard into is never removed from the component tree. The way I do it is to add the SessionGuard directly to the main window, and make sure that view changes don’t change the main window’s layout, but another layout that’s a sibling to the SessionGuard.
If you’ve ever used a globally functioning UriFragmentUtility, the idea is exactly the same.
The sessionguard was not there.
In the Application, I did add SessionGuard to the main Window.
But later, Navigator7 called Window.setContent() which removed the layout containing the session guard.
The right place for me is to instantiate the SessionGuard in my descendant of NavigableApplicationWindow.createComponent() method.
Now sessionguard is there, and it seems to work.
Thank you Henrik!
No problem John! I’m just glad that you got the thing sorted out.
Would be great if the add-on allowed custom handling of the timeout. For me, displaying just the notification is not enough. I would like to be able to set a listener to the SessionGuard component which would notify me when the time runs out and I could perform any arbitrary action.
But anyway it’s a great add-on, keep up the good work!