Hi, you can use the runtime service defined by the Http Whiteboard spec to find out whether something is still registered. The only downside is that you need to poll and check the DTOs until the desired state is reached. But for testing this should be totally fine.
However, it would be great if we could further pinpoint the problem and avoid the duplicate requests in general. Carsten Tom Quarendon wrote >> If that is not the case setting a break point in the DispatcherServlet from >> Felix will tell you whether the request is called twice from outside the >> Felix http implementation (Jetty in that case then) or now. > > The implication of this (I haven't looked into the felix code at this point, > and actually all of the source links for the HTTP projects on the felix > download page seem to be broken, I've tried numerous mirrors) is that there > is a single servlet that you register with jetty, and then you manage > distributing the request to the relevant servlet? > > We are as sure as we can be that there is only one HTTP request made, and two > calls to the server. We've turned on Jetty tracing and logged our own servlet > and this appears to be the case. Up until recently we haven't had a reliable > way to reproduce it, but the technique of editing the code in a debug session > so that you can force it to redeploy the component while it's in the middle > of processing the request appears to work. > > Since my original post, I realise that in some ways it's not interesting why > the problem occurs, or actually "solving" it (clearly, to me, POST being > processed twice is a bug somewhere). > Instead what we want is to make our tests reliable. And I think what this > means is that we need a way of waiting until everything is shut down after > each test. If we had a way of detecting whether all servlets had been > deregistered, then that might help. We suspect that although our test has > finished, background reconfiguration occurs within OSGi, and this is still > happening when the next test starts. It then makes a request that gets > handled by a servlet that is in the process of being shut down. If we could > avoid all of that, and ensure that we go back to a clean slate each time, > that's probably what we really need. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Carsten Ziegeler Adobe Research Switzerland [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
