Community
Participate
Working Groups
Build Identifier: 7.5.1 It seems that HttpSessionListener.sessionDestroyed() call is async to BundleContext invalidation process (during WAB stop). Reproducible: Always Steps to Reproduce: 1. Start WAB with HttpSessionListener 2. In HttpSessionListener.sessionDestroyed() implement access to BundleContext (get/unregister some services.) To check whether call is async - add some Thread.sleep() 3. stop WAB 4. Check logs for IllegalStateException
Dmytro, How are you starting and stopping the web app bundle? Jan
Jan, the WAB is started automatically. I stop bundle manually. Dmytro
Dmytro, What jetty bundles do you have deployed? Also, do you have a jetty.xml file configured? Jan (In reply to comment #2) > Jan, > > the WAB is started automatically. I stop bundle manually. > > Dmytro
Jan, Jan, jetty bundles: - org.eclipse.jetty.aggregate.jetty-all-server_7.5.1.v20110908.jar - org.eclipse.jetty.osgi.boot.jsp_7.5.1.v20110908.jar - org.eclipse.jetty.osgi.boot_7.5.1.v20110908.jar jetty.xml is a part of jetty configuration bundle that is defined with jetty.home.bundle property. Dmytro (In reply to comment #3) > Dmytro, > > What jetty bundles do you have deployed? Also, do you have a jetty.xml file > configured? > > Jan > > (In reply to comment #2) > > Jan, > > > > the WAB is started automatically. I stop bundle manually. > > > > Dmytro
Dmytro, I don't think you need the jetty aggregate jar. All required classes should be available via the jetty.osgi.boot jar. Why did you need that? Could you make a small webapp with the appropriate HttpSessionListener and attach so I can reproduce? thanks Jan (In reply to comment #4) > Jan, > > Jan, > > jetty bundles: > - org.eclipse.jetty.aggregate.jetty-all-server_7.5.1.v20110908.jar > - org.eclipse.jetty.osgi.boot.jsp_7.5.1.v20110908.jar > - org.eclipse.jetty.osgi.boot_7.5.1.v20110908.jar > > jetty.xml is a part of jetty configuration bundle that is defined with > jetty.home.bundle property. > > Dmytro > > (In reply to comment #3) > > Dmytro, > > > > What jetty bundles do you have deployed? Also, do you have a jetty.xml file > > configured? > > > > Jan > > > > (In reply to comment #2) > > > Jan, > > > > > > the WAB is started automatically. I stop bundle manually. > > > > > > Dmytro
Hello Jan, I use aggregate jetty jar as a replacement of Jetty multiple-bundles (jatty-server etc.) configuration. jetty.osgi.boot is just an activator for jetty server. Best regards, Dmytro (In reply to comment #5) > Dmytro, > > I don't think you need the jetty aggregate jar. All required classes should be > available via the jetty.osgi.boot jar. Why did you need that? > > Could you make a small webapp with the appropriate HttpSessionListener and > attach so I can reproduce? > > thanks > Jan > > (In reply to comment #4) > > Jan, > > > > Jan, > > > > jetty bundles: > > - org.eclipse.jetty.aggregate.jetty-all-server_7.5.1.v20110908.jar > > - org.eclipse.jetty.osgi.boot.jsp_7.5.1.v20110908.jar > > - org.eclipse.jetty.osgi.boot_7.5.1.v20110908.jar > > > > jetty.xml is a part of jetty configuration bundle that is defined with > > jetty.home.bundle property. > > > > Dmytro > > > > (In reply to comment #3) > > > Dmytro, > > > > > > What jetty bundles do you have deployed? Also, do you have a jetty.xml file > > > configured? > > > > > > Jan > > > > > > (In reply to comment #2) > > > > Jan, > > > > > > > > the WAB is started automatically. I stop bundle manually. > > > > > > > > Dmytro
Dmytro, I've been testing this with virgo and trying a few different things. It seems to me that there is an error in BundleContext implementation - although the state of the Bundle is STOPPING, calls to the BundleContext throw IllegalStateException, but the javadoc indicates that the BundleContext should be valid during STOPPING: "The BundleContext object is only valid during the execution of its context bundle; that is, during the period from when the context bundle is in the STARTING, STOPPING, and ACTIVE bundle states. If the BundleContext object is used subsequently, an IllegalStateException must be thrown." Here's a snippet from the trace with some extra debug added. It shows that the same thread is used throughout the stopping of the Bundle, and ServiceEvent handing: [2012-05-04 18:50:19.766] INFO qtp1211083840-82 org.eclipse.virgo.medic.eventlog.default DE0010I Stopping bundle 'org.eclipse.jetty.test-jetty-webapp' version '7.6.4.SNAPSHOT'. [2012-05-04 18:50:19.770] ERROR qtp1211083840-82 System.err ServiceChanged, unregistering o.e.j.w.WebAppContext{/foo,file:/usr/local/java/jetty/virgo-jetty-server-3.0.0.BUILD-20110610102656-janb/work/org.eclipse.virgo.kernel.deployer_3.0.0.D-20110603101321/staging/global/bundle/org.eclipse.jetty.test-jetty-webapp/7.6.4.SNAPSHOT/test.jar/},file:/usr/local/java/jetty/virgo-jetty-server-3.0.0.BUILD-20110610102656-janb/work/org.eclipse.virgo.kernel.deployer_3.0.0.D-20110603101321/staging/global/bundle/org.eclipse.jetty.test-jetty-webapp/7.6.4.SNAPSHOT/test.jar/ bundle state=16 by thread: Thread[qtp1211083840-82,5,main] [2012-05-04 18:50:19.773] ERROR qtp1211083840-82 System.err sessionDestroyed javax.servlet.http.HttpSessionEvent[source=org.eclipse.jetty.server.session.HashedSession:lwh0hb8z6up2d8yzrzkw5z2s@329990845] [2012-05-04 18:50:22.773] ERROR qtp1211083840-82 System.err Session destroyed thread=Thread[qtp1211083840-82,5,main] bundle.state=16 [2012-05-04 18:50:22.796] WARN qtp1211083840-82 org.eclipse.jetty.util.component.AbstractLifeCycle FAILED org.eclipse.jetty.server.session.HashSessionManager@1adf86b7: java.lang.IllegalStateException: BundleContext is no longer valid What environment are you testing this on? Can you confirm my (limited) understanding of the OSGi behaviour? thanks Jan
Looks to me like an incorrect implementation in Eclipse org.osgi.framework.interna.core.BundleContextImpl class. See line 80: http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse/osgi/3.7.0/org/eclipse/osgi/framework/internal/core/BundleContextImpl.java#BundleContextImpl.close%28%29 At this point, the state of the associated Bundle is still STOPPING, however, the BundleContextImpl class is set to invalid *before* the ServiceListeners are called.
Dymtro, As you can see from bug #358074, the osgi framework guys contend that the BundleContext is not guaranteed to be available when the Bundle is STOPPING. So, it would seem it is immaterial that the BundleContext validity might be being set asynchronously. I think your code will need to not rely on access to the BundleContext in sessionDestroyed(). regards Jan (In reply to comment #8) > Looks to me like an incorrect implementation in Eclipse > org.osgi.framework.interna.core.BundleContextImpl class. > > See line 80: > > http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse/osgi/3.7.0/org/eclipse/osgi/framework/internal/core/BundleContextImpl.java#BundleContextImpl.close%28%29 > > At this point, the state of the associated Bundle is still STOPPING, however, > the BundleContextImpl class is set to invalid *before* the ServiceListeners are > called.
Jan, Is HttpSessionListener#sessionDestroyed() async call? I have to handle somehow WAB stop procedure to release some resources/make clean up in OSGi framework (remove temporary bundles that were created during WEB session etc.). When WAB is active - everything works fine, because BundleContext is valid. When WAB is stopping I expect that HttpSessionListener is called in sync way to handle session destroy event correctly. Should I use ServletContextListener in this case? Thanks, Dmytro (In reply to comment #9) > Dymtro, > > As you can see from bug #358074, the osgi framework guys contend that the > BundleContext is not guaranteed to be available when the Bundle is STOPPING. > > So, it would seem it is immaterial that the BundleContext validity might be > being set asynchronously. > > I think your code will need to not rely on access to the BundleContext in > sessionDestroyed(). > > regards > Jan > > (In reply to comment #8) > > Looks to me like an incorrect implementation in Eclipse > > org.osgi.framework.interna.core.BundleContextImpl class. > > > > See line 80: > > > > http://grepcode.com/file/repository.grepcode.com/java/eclipse.org/3.7/org.eclipse/osgi/3.7.0/org/eclipse/osgi/framework/internal/core/BundleContextImpl.java#BundleContextImpl.close%28%29 > > > > At this point, the state of the associated Bundle is still STOPPING, however, > > the BundleContextImpl class is set to invalid *before* the ServiceListeners are > > called.
Dmytro, I think there's a possibility it could be asyc at the moment, but I changed things to ensure that it is called back synchronously, and it didn't make any difference, the BundleContext was still invalid. So even if I made it synchronous, it won't help you. Even if you do it in a ServletContextListener, the bundle will already be in the same STOPPING state where the BundleContext isn't valid. Can you store the values you want to access from the BundleContext in the session rather than the bundleContext object itself? Jan
Jan, I've made some analysis of OSGI Ent spec (128.3.8 Stopping the WAB) and Servlet 2.5 Spec (10.3.4 Notification of Shutdown) As I understood correctly, when WAB is stopping Web App is switched to UNDEPLOYING state and all Web App resources should be cleaned up/all listeners should be called in the order described in Servlet Spec. I expect that at this moment BundleContext should be valid. (from OSGi spec: "...In response to a WAB STOPPING event, the Web Extender must undeploy the corresponding Web Application from the Servlet Container and clean up any resources. This undeploying must occur synchronously with the WAB’s stopping event...") Then Web App is switched to UNDEPLOYED state and BundleContext could be invalid. Thanks, Dmytro
Jan, I use some services from OSGi registry. I'd not like to cache them in the session. Dmytro (In reply to comment #11) > Dmytro, > > I think there's a possibility it could be asyc at the moment, but I changed > things to ensure that it is called back synchronously, and it didn't make any > difference, the BundleContext was still invalid. So even if I made it > synchronous, it won't help you. Even if you do it in a ServletContextListener, > the bundle will already be in the same STOPPING state where the BundleContext > isn't valid. Can you store the values you want to access from the BundleContext > in the session rather than the bundleContext object itself? > > Jan
(In reply to comment #12) > Jan, > > I've made some analysis of OSGI Ent spec (128.3.8 Stopping the WAB) and Servlet > 2.5 Spec (10.3.4 Notification of Shutdown) > > As I understood correctly, when WAB is stopping Web App is switched to > UNDEPLOYING state and all Web App resources should be cleaned up/all listeners > should be called in the order described in Servlet Spec. I expect that at this > moment BundleContext should be valid. (from OSGi spec: "...In response to a WAB > STOPPING event, the Web Extender must undeploy the corresponding Web > Application from the Servlet Container and clean up any resources. This > undeploying must occur synchronously with the WAB’s stopping event...") > > Then Web App is switched to UNDEPLOYED state and BundleContext could be > invalid. > > Thanks, > Dmytro If you use SynchronousBundleListener to handle STOPPING event and uninstall WebApp in the same thread - BundleContext should be valid. This way is equal to BundleActivator#stop() method. Dmytro.
Dmytro, Have a read of the thread in this bugzilla here (sorry, I pasted the wrong link earlier, probably adding to the confusion): https://bugs.eclipse.org/bugs/show_bug.cgi?id=378571 I changed the jetty code here to use synchronous osgi listeners, and yet the BundleContext was still invalid. The OSGi guys said that this was to be expected. If you can propose a method that will work, taking into account what BJ Hargreave has already said about this, then I'm happy to try to implement it, however if the position from the OSGi guys is that you cannot rely on the BundleContext during stopping, I don't really see that there's much we can do. You could maybe try registering a synchronous bundle listener yourself, or a bundle activator class, and try doing the cleanup in there? Jan (In reply to comment #14) > (In reply to comment #12) > > Jan, > > > > I've made some analysis of OSGI Ent spec (128.3.8 Stopping the WAB) and Servlet > > 2.5 Spec (10.3.4 Notification of Shutdown) > > > > As I understood correctly, when WAB is stopping Web App is switched to > > UNDEPLOYING state and all Web App resources should be cleaned up/all listeners > > should be called in the order described in Servlet Spec. I expect that at this > > moment BundleContext should be valid. (from OSGi spec: "...In response to a WAB > > STOPPING event, the Web Extender must undeploy the corresponding Web > > Application from the Servlet Container and clean up any resources. This > > undeploying must occur synchronously with the WAB’s stopping event...") > > > > Then Web App is switched to UNDEPLOYED state and BundleContext could be > > invalid. > > > > Thanks, > > Dmytro > > > If you use SynchronousBundleListener to handle STOPPING event and uninstall > WebApp in the same thread - BundleContext should be valid. This way is equal to > BundleActivator#stop() method. > > Dmytro.
