Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 411102

Summary:	Application context is not active in UISessionListener#beforeDestroy under some constellations
Product:	[RT] RAP	Reporter:	Ivan Furnadjiev <ivan>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P2	CC:	wolfgang.pedot
Version:	unspecified
Target Milestone:	2.3 M2
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Ivan Furnadjiev

2013-06-19 06:17:01 EDT

I'm opening this bug to track down the real cause for bug 410993. If you add the following code to our Controls Demo:
...
RWT.getUISession().addUISessionListener( new UISessionListener() {
   public void beforeDestroy( UISessionEvent event ) {
     System.out.println( RWT.getApplicationContext() ); // returns null
     System.out.println( RWT.getUISession().getApplicationContext() ); // returns deactivated application context
   }
} );
...
and type "shutdown" in the OSGi console you will get a null application context in UISessionListener. The application context has been already deactivated at that point. Usually the application context is active there.

Comment 1 Ivan Furnadjiev

2013-06-19 06:45:25 EDT

Quote a related comment from Frank in UIThread#processShutdown:
"TODO [fappel]: Think about a better solution: isActivated() checks whether the applicationContext is still activated before starting cleanup. This is due to the missing possibility of OSGi HttpService to shutdown HttpContext instances. Therefore sessions will survive the deactivation of ApplicationContext instances. In case the HttpService gets halted the corresponding ApplicationContext instances have already been deactivated and this will cause a NPE."

Comment 2 Ralf Sternberg

2013-11-25 10:04:07 EST

This could be related to bug 422472. When a server push request is waiting, the servlet container may not terminate HTTPSessions. In this case, the ApplicationContext is deactivated, but the UISessions are still alive.

We should consider to destroy all UISessions on ApplicationContext deactivation. If we decide to do so, commit 6916db631aa7f7772eb73c8799f864cb37d8162d can be revoked.

Comment 3 Ivan Furnadjiev

2014-03-06 08:15:12 EST

Destroy all UISessions on ApplicationContext deactivation with change https://git.eclipse.org/r/22962.

Comment 4 Wolfgang Pedot

2014-04-18 06:58:06 EDT

I think this change introduced another problem:

UISessionImpl does register itself as a listener with the ApplicationContext on creation but it does not unregister when it gets destroyed because of timeout or some other reason. This means UISessionImpl objects are leaking and cause a lot of exceptions when the ApplicationContext finally gets terminated because the corresponding HttpSessions may not be valid any more.

I ran into this problem when testing our RAP application (jetty-based) with the current master from git.eclipse.org. Adding 

if( applicationContext != null ) {
  applicationContext.removeApplicationContextListener( this );
}

in the destroy-method of UISessionImpl fixed it for me.

Comment 5 Ivan Furnadjiev

2014-04-18 07:52:01 EDT

Reopening based on latest comment and set the priority to P2.

Comment 6 Ivan Furnadjiev

2014-04-22 06:31:31 EDT

(In reply to comment #4)
> I think this change introduced another problem
Fixed with change https://git.eclipse.org/r/25333.