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.

Ed


On Wed, 22 Jul 2015 19:33:28 +0200, Achim Nierbeck <[email protected]> 
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 <[email protected]>:
> 
> >
> > 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 <[email protected]>
> > 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 <[email protected]> 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 <[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
> >
> >
> >
> 
> 
> -- 
> 
> 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


Reply via email to