Hi Rob Yeah, I would think so.
I would think it is just a regression from some Jetty migrations in the past… Regards Felix Am 26.08.2014 um 13:34 schrieb Rob Walker <[email protected]>: > Thanks Felix - that's how I read it also. > > Not urgent for me at present - I have an internal PR to migrate our App to > the latest HTTP Jetty version anyone, so maybe I'll take a look at wiring > that debug flag back in at the same time. > > Do you think it's worth raising a JIRA report for it? > > -- Rob > > On 26/08/2014 12:01, Felix Meschberger wrote: >> Hi >> >> If I see it correctly it all happens in the Jetty >> org.eclipse.jetty.util.log.Log class, which by defaults sets up logging to >> SLF4J which can be overwritten by setting the >> „org.eclipse.jetty.util.log.class“ property. >> >> Looking at JettyConfig it seems that the debug flag is not currently used. >> It is exposed in the isDebug method, but that does not seem to be called. I >> would think we would have to „fix“ that in the JettyServer class when >> starting Jetty up — really early similar to how we „fix“ the jetty.version >> setup. >> >> Regards >> Felix >> >> >> Am 26.08.2014 um 09:18 schrieb Rob Walker <[email protected]>: >> >>> I'm being lazy here I know, but anyone remember offhand the set of >>> properties required to get Jetty's own internal tracing/logging piped >>> through to the OSGi logging. Scanning the code quickly, I can see the >>> JettyLogger class but my head is not quite connecting the dots on how to >>> get that active. >>> >>> The org.apache.felix.http.debug = true is fine for service logs, but I'm >>> after the low level tracing that Jetty spits out as it processes requests >>> >>> I know this used to just be as simple as setting the old DEBUg=true flag >>> and using the Jetty StdErrLog flag, but obviously moved on since those days! >>> >>> Cheers >>> >>> --Rob >>> >>> > > -- > > > Ascert - Taking systems to the edge > [email protected] > SA +27 21 300 2028 > UK +44 20 7488 3470 ext 5119 > www.ascert.com >
