> On Jul 22, 2015, at 2:39 PM, Ed Welch <e...@edjusted.com> wrote: > > Hi Achim! > > I set out on that path this morning, but it looks like the camel-cxf feature > in camel 2.15.2 has a dependency or a dependent feature with an upper bound > which won't accept jetty 9: > > Error executing command: Unable to resolve root: missing requirement [root] > osgi.identity; osgi.identity=jetty; type=karaf.feature; > version="[7.0.0,9.0.0)" > > I haven't had a chance to look/try a snapshot camel build, or figure out what > exactly is imposing that requirement > > cxf, camel, and jetty features all installed fine, I got that error when > installing camel-cxf feature.
Install CXF 3.1.1 first, then install camel and camel-cxf. You need to make sure you are grabbing 3.1.1 as that’s the first version that supports Jetty9. Dan > > Ed > > > On Wed, 22 Jul 2015 19:33:28 +0200, Achim Nierbeck <bcanh...@googlemail.com> > wrote: > >> Hi Ed, >> >> if you use Karaf4 and/or Pax-Web 4.x you'll get Jetty 9 for free :-) >> >> regards, Achim >> >> >> 2015-07-22 17:24 GMT+02:00 Ed Welch <e...@edjusted.com>: >> >>> >>> configuring CXF to be synchronous definitely removes the stack trace, so >>> it does appear to be an async issue with Jetty. >>> >>> I sent a message to their list and they nudged me to try jetty 9 to see if >>> it's been fixed. However, camel-cxf seems to have a requirement for jetty >>> < 9 and I wasn't able to install it >>> >>> Do you know if current snapshot builds for camel-cxf will work with jetty >>> 9? >>> >>> If not, I will probably sit on this for a while, or see if i can setup >>> straight CXF to do async calls with jetty 9. >>> >>> If the issue exists in 9, I will try to sort through it with the jetty >>> group, if it was fixed in 9, I will leave it up to them to see if they are >>> going to fix 8. >>> >>> This doesn't really seem to be a show stopper for anyone I'm guessing, >>> else it probably would have got more attention. >>> >>> Thanks Claus you do great work! >>> >>> On Wed, 22 Jul 2015 06:18:47 +0200, Claus Ibsen <claus.ib...@gmail.com> >>> wrote: >>> >>>> Hi >>>> >>>> You can configure CXF to be synchronous with ?synchronous=true on the >>>> camel endpoint uri. >>>> >>>> On Tue, Jul 21, 2015 at 7:54 PM, Ed Welch <e...@edjusted.com> wrote: >>>>> Thanks Claus, >>>>> >>>>> You got the wheels turning a little, and I spent some more time with >>> the debugger. >>>>> >>>>> I have found a section of Jetty code of interest, and I'm going to >>> reach out to their mailing list to see what they think. >>>>> >>>>> I documented in a little more detail in the running pax-web issue i >>> opened if you are curious: >>> https://ops4j1.jira.com/browse/PAXWEB-863?focusedCommentId=28843&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-28843 >>>>> >>>>> In summary, it appears the camel-cxf component is doing some ASYNC >>> processing with jetty, and I'm suspicious that Jetty has a conditional that >>> should also be looking for ASYNC request types when checking to see if a >>> request has already been handled by another handler. >>>>> >>>>> The plain cxf example I created does not appear to do any ASYNC >>> operations, which is why it's not seeing this issue. >>>>> >>>>> Will post back for posterity if I make progress with Jetty >>>>> >>>>> On Mon, 20 Jul 2015 21:46:44 +0200, Claus Ibsen <claus.ib...@gmail.com> >>> 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 <e...@edjusted.com> 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 >>> >>> >>> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >> Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master > > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
