project not running as a portal but as a portlet

I had a project which was running as a portal, and recently brought it back
down. Websphere did not recognize it as a webfacing project, so I imported it
into a new  workspace and migraged it to 1.4 and latest version of webfacing.

Now, we can it run it in a brower session. However when we click on the link to
start running it from scratch, i.e. the initial URL, we get a error page:

Problem

An attempt was made to start a second WebFacing session in a single browser
instance

it allows you to click on a link to return where you were, were in the past you
would be directed to were everything was refreshed. This is a big change for our
web users. Any ideas how to get back to the old way of behaviour?

rod.luciuk@scic.gov.sk.ca wrote:
> I had a project which was running as a portal, and recently brought it back
down. Websphere did not recognize it as a webfacing project, so I imported it
into a new  workspace and migraged it to 1.4 and latest version of webfacing.
> 
> Now, we can it run it in a brower session. However when we click on the
link to start running it from scratch, i.e. the initial URL, we get a error
page:
> 
> Problem
> 
> An attempt was made to start a second WebFacing session in a single browser
instance
> 
> it allows you to click on a link to return where you were, were in the past
you would be directed to were everything was refreshed. This is a big change for
our web users. Any ideas how to get back to the old way of behaviour?
> p.s. No error message shows up in the console.

I don't 100% understand your question.  Are you talking about a 
WebFacing Portlet project in WPS or a WebFacing Web project running in 
WAS?  That is if WebFacing was running as a portlet in the WebSphere 
Portal Server I would not expect that you should see that message.

If you are running as a normal Web project in WAS then you should expect 
to see that message if, for instance, you launch a WF program then use 
the back button back to the index page and try and launch another (or 
the same) WF program or if you launch a WF program in one tab of IE7 
then try to do the same in another tab.  What WF is doing is a simple 
check to see if the current session is already associated with a running 
program and trying to prevent a new launch from overwriting a currently 
running program.  If you run a program and end it then you should be 
able to run another one with no problem.

With the original behavior the second launch would orphan the user 
job(s) in the iSeries and it would not be ended until after the session 
timeout.  With the introduction of tabbed browsing with IE there is 
perceived to be an increased chance of this happening inadvertently. 
There is a setting in the web.xml that can be used to turn this off but 
I'd have to look it up (not handy at the moment).  But is allowing users 
to orphan iSeries jobs really what you want ?

We are running as a WebFacing Web project running in WAS.

I am wondering what has caused the change in behavour? We have other WebFacing
Projects that don't display this session error. Also when I check, I only see
one session in work active jobs for these jobs when reexcuted.
I am assuming that if this is a setting  it must have been set by default in the
older projects, and importing changed the setting.
 
If you have the setting for the web.xml file, that would be great. I compared
the web.xml from the original to the newly created one, and have set them to be
the same(execpt for unique ID's), but still have the same behaviour. 

Our web users in number of cases would like to have more then one tab going to
compare different results, as indicated by the message, this would have to be
done by moving this to a portal project. Is this what part of the message
implies? ("If you wish to run more than one WebFacing application at the
same time start another browser instance. This restriction does not exist when
running WebFacing in a Portal environment.")


As a side issue, is it possible to trap and redirect the session error for this
back to the jsp that it came from(instead of having the user click on the
link)?

rod.luciuk@scic.gov.sk.ca wrote:
> We are running as a WebFacing Web project running in WAS.
> 
> I am wondering what has caused the change in behavour? We have other
WebFacing Projects that don't display this session error. Also when I check, I
only see one session in work active jobs for these jobs when reexcuted.
> I am assuming that if this is a setting  it must have been set by default
in the older projects, and importing changed the setting.
>  
> If you have the setting for the web.xml file, that would be great. I
compared the web.xml from the original to the newly created one, and have set
them to be the same(execpt for unique ID's), but still have the same behaviour.

> 
> Our web users in number of cases would like to have more then one tab going
to compare different results, as indicated by the message, this would have to be
done by moving this to a portal project. Is this what part of the message
implies? ("If you wish to run more than one WebFacing application at the
same time start another browser instance. This restriction does not exist when
running WebFacing in a Portal environment.")
> 
> 
> As a side issue, is it possible to trap and redirect the session error for
this back to the jsp that it came from(instead of having the user click on the
link)?
> 
> Thanks for your response.

OK I understand now, it would be reasonable to see the message in that 
environment.

That change was introduced in the last update to the WebFacing plugin. 
The session reuse protection would be applied to any new projects and to 
existing projects that are migrated to the current version.  And yes, 
you are right, with recent optimizations in the runtime we reuse the WF 
session objects if they exist and part of that is to logoff and close 
any existing connections - which would end it a endjob of the previous 
program.

In a tabbed browser, all tabs are in the same session (same session 
cookie).  For the Web environment WebFacing currently only supports 
running one invocation per session. So, if you disable the protection 
and try a second invocation of the same webapp in a second tab it will 
take over the session and the job associated with the previous tab will 
be ended.  The session reuse check was put in to protect the user from 
this happening.

You could modify the sessionerror.jsp or the struts config to go where 
ever you prefer.

I still have not looked up the parm name for the web.xml but it is 
something like WFIgnoreSessionReuseCheck but I would use it with caution.