Hi Yes it looks like that is the problem we had on fabric8 v1 also
https://github.com/rhuss/jolokia/blob/master/agent/osgi/src/main/java/org/jolokia/osgi/security/BasicAuthenticationHttpContext.java#L49 On Mon, Jul 20, 2015 at 9:46 PM, Claus Ibsen <[email protected]> wrote: > Hi > > I have seen those errors to on fabric8 v1. It was when using servlet > sendError that caused that bug/issue with jetty. Instead you would > have to build the reply message normally and set status code to an > error code, then it worked - eg do not use the sendError method on the > servlet api. > > I wonder if that is what Jolokia does at > BasicAuthenticationHttpContext. And if so maybe that code can be > changed. > > On Sat, Jul 18, 2015 at 8:58 PM, Ed Welch <[email protected]> wrote: >> I've been trying to get to the bottom of this for a couple weeks now, and >> I'm stuck.... >> >> I'll try to keep things as short as possible, but basically, I have a soap >> webservice created with the camel cxf component, running in karaf 3.0.3, >> java 8 update 25, camel 2.15.2, cxf 3.0.4 (simple sample project linked at >> the end) >> >> And if the jolokia-osgi bundle is installed, every call to my webservice >> results in a rather nasty stack trace in the log file: >> >> 2015-07-18 14:37:03,379 | WARN | qtp23458725-67 | Response >> | 71 - org.eclipse.jetty.aggregate.jetty-all-server - >> 8.1.15.v20140411 | Committed before 401 null >> 2015-07-18 14:37:03,379 | WARN | qtp23458725-67 | AbstractHttpConnection >> | 71 - org.eclipse.jetty.aggregate.jetty-all-server - >> 8.1.15.v20140411 | /cxf/test/ >> java.lang.IllegalStateException: Committed >> at >> org.eclipse.jetty.server.Response.resetBuffer(Response.java:1154)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >> at >> org.eclipse.jetty.server.Response.sendError(Response.java:317)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >> at >> org.eclipse.jetty.server.Response.sendError(Response.java:419)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >> at >> javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:137)[65:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0.0] >> at >> org.jolokia.osgi.security.BasicAuthenticationHttpContext.handleSecurity(BasicAuthenticationHttpContext.java:49)[144:org.jolokia.osgi:1.3.1] >> at >> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:68)[80:org.ops4j.pax.web.pax-web-jetty:3.1.4] >> at >> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[71:org.eclipse.jetty.aggregate.jetty-all-server:8.1.15.v20140411] >> ... >> >> I abbreviated the trace, the full stack can be found in the jira link >> further down, but you can see in the stack it's trying to call the >> org.jolokia.osgi.security.BasicAuthenticationHttpContext, which is bizzare >> >> Ok, so first thing to mention, the webservice call works fine, and works >> fine every time, the error in the logs occurs after the client receives a >> successful response >> >> At first I thought this was an issue with pax-web, so I opened a ticket over >> there: >> >> https://ops4j1.jira.com/browse/PAXWEB-863 >> >> Achim very nicely spent some time looking into this, and has not been able >> to find any issues with the pax-web code. >> >> So out of curiosity, I setup a straight CXF soap webservice in the same >> environment, and it works great, no errors even when jolokia is installed. >> >> This has lead me over to camel, or how camel is using CXF >> >> I've spent a few hours with the debugger but I'm really not getting >> anywhere, everything looks to me like jetty is processing the call through >> camel/cxf as it should, and then a second process is made to through the >> context jolokia registers when its installed, and this results in the error >> (because the jolokia context looks for the Authorization header, doesn't see >> it, throws an exception back to the client, but the connection to the client >> is already closed because it was handled and closed in the successful camel >> call) >> >> But this second call stack is mostly jetty and some pax-web classes. So it >> doesn't look like camel code is directly causing this. >> >> Some of my thoughts are how the webservice is registered with cxf and in >> turn with pax/jetty in the osgi environment, or maybe there is some kind of >> missing "handled" notification to jetty to keep it from sending he request >> to more contexts? I dunno if that second thing is real or not, just >> thinking outloud. >> >> I made a sample project to make this easier to test: >> https://github.com/erwelch/paxweb-863 >> >> I'm afraid I'm at a loss for how to further debug this, I'm not convinced >> this is a camel issue, but since it's the case I can only re-create this >> using camel, I'm hoping someone can help! >> >> Thanks, >> Ed > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2nd edition: http://www.manning.com/ibsen2 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2nd edition: http://www.manning.com/ibsen2
