I'm glad that you have a simple case working :) The reason I wanted to see the manifests is that it sounds like you have an inconsistent class space, and the new implementation cannot be used without re-wiring the consumer. Does your service-providing bundle export any packages? If so does your service-consuming bundle import them? They don't have to be related to the service for it to start causing problems.
Tim Date: Mon, 23 Jul 2012 20:34:27 +0200 Subject: Re: ReferenceRecipe waits although service is available again From: balazs.zsol...@everit.biz To: user@aries.apache.org Hi, thank you for offering your help. I tried to create a more simple use case (with non-business logic bundles) however I could not reproduce the problem. This is good news as blueprint works :). I will try to add every dependency we use in our system (hibernate, myfaces, ...) and try to find the cause of the problem. If I can reproduce it but cannot find the cause I will prepare a sample application with a full testing environment (ready to use equinox with libraries inside). I will not have time in the following couple of days but I will get back to this. If I find the cause I will drop a mail anyway to let others know what caused the hangs. Thanks and regards,Balazs On Fri, Jul 20, 2012 at 6:01 PM, Timothy Ward <timothyjw...@apache.org> wrote: Hi, Could you send the manifests of the three bundles, and the manifest of the updated core bundle? I'd like to check for class-space issues. Regards, Tim Date: Fri, 20 Jul 2012 10:20:25 +0200 Subject: ReferenceRecipe waits although service is available again From: balazs.zsol...@everit.biz To: user@aries.apache.org Hi, I have a problem. Please help me finding out if this is a bug or my use case is wrong. There are three bundles:API bundle: Contains an interface A Core bundle: Contains the implementation of A and provides it as a serviceServlet bundle:Contains Servlet classesContains a ServletActivator class that has init, destroy method and A property A blueprint configuration that sets the A property in the ServletActivator and calls the init methodThe init method instantiates the servlet and passes it to org.osgi.service.http.HttpService I start Equinox, everything is fine. I can see the servlet running well. I say an update command on the Core bundle and I see that the service is unregistered and registered again provided by this bundle. After an http request will stop at the line below until a timeout: "qtp1313052129-27" prio=6 tid=0x000000000873d800 nid=0x2498 in Object.wait() [0x000000001105d000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:202) - locked <0x0000000782888a68> (a java.lang.Object) at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:56) at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:290) at Proxy18044d63_3609_456d_82b5_803c25785628.getCurrentPresenseForAdspace(Unknown Source) at ..................................MyServlet.service(MyServlet.java:76) at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:109) at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:350) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:620) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538) In two of my applications it is always reproducable. Please let me know if you see the problem based on the stacktrace by looking at it or if I should provide a sample applicaiton. It would be really nice to solve this before 1.0.0 release comes out as this really stops our TDD development workflow. There is another problem based on this: If I update the Servlet bundle just after updating the core bundle everything works fine. However if I update the Core bundle, make an http request and than try updating the web bundle will be locked until the timeout (basically I cannot process any osgi related command in the container as a bundle stopping is locked). Thanks and regards,Balazs Zsoldos