> 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: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
