portlet view's bean expires before session?

We’ve got following problem with CAF application (task portlet) on MWS 8.2+SP1:

When there is long period of user inactivity (about 30 minutes) between task’s form display and user actions (for exapmple task submit or task completion) the data stored in Task View managed bean is lost. The session timeout is not a problem (session is configured to 240 minutes) and is not expired. However when we try to get task’s data from bean (or generally any other data referenced by view bean) in action java code, all atributtes are null (after that period of user inactivity). The same data is not lost when there is not long period of user inactivty.

It all looks like view’s managed bean expires before session ends. Managed bean is configured (faces-config.xml) as “session” and we tried set “expireWithPageFlow” to true and to false (both settings don’t solve the problem).

I found issue MWS-6541 (second issue) in [url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuites/wmsuite8-2_ga/readme/MywebMServer_8-2-SP1_readme.pdf[/url] which looks simillar to our problem (the managed bean lives shorter than it is declared in faces-config.xml).

However this is not clear, how to implement workaround.

Anyone can help with this issue?


Sorry about the delayed response. I think what you’ll need to do is to ensure that the session-timeout in the deploy/portal.war/WEB-INF/web.xml file is also set in your Portlet Application’s web.xml.

Please let me know if that helps.

Yes, it works.
We’d default application’s web.xml, generated by wM Designer and it didn’t have session-timeout parameter at all. When I added this parameter to web.xml, beans are not expiring before portal session.

This is strange behavior of MWS, because you must remember to change timeout for each application when you want to change portal session. I’d expect that if I don’t set application’s session-timeout it is inherited from portal’s web.xml.
Is it intetional behavior?

Anyway, many thanks for this workaround Mark!

Marcin Warda

I agree with you. If you’d like you could raise a support issue referencing this thread and we can see about getting an official fix out that addresses this.