I'm thinking if I had access to the Jetty server instance and with these two classes I could probably pull it off. Report back soon if it works.
http://svn.apache.org/repos/asf/logging/log4j/trunk/contribs/JimMoore/LoggingOutputStream.java http://commons.apache.org/io/apidocs/org/apache/commons/io/input/TeeInputStream Tim ----- Original Message ---- > From: Tim Harsch <[email protected]> > To: [email protected] > Sent: Fri, May 20, 2011 9:58:10 AM > Subject: Re: Fuseki server log > > That's a great idea actually, I'll look into it. One thing I've noticed > about > > the code that might make this some work is that the servlets are configured > in > > code which are in private variables several steps down in the call stack. > Is > there an easy way to get access to the servlets that I don't see, or could I >ask > > that a public getter be defined for the next release? > > Thanks, > Tim > > > ----- Original Message ---- > > From: Andy Seaborne <[email protected]> > > To: [email protected] > > Sent: Fri, May 20, 2011 1:18:18 AM > > Subject: Re: Fuseki server log > > > > The HTTP response line has a number (status code) and a text string. > > That's what appears in the log > > > > "200 OK" > > "404 Not Found" > > > > The actual string can vary: > > > > "404 Sorry - I have no clue what you are talking about" > > > > The results go in the body. In Fuseki, the results are streamed. > > Because they are potentially large, they aren't sent near the logs > > because I don't want the string bashing overhead. > > > > Joseki tends to serialize the results to check the query is going to > > work, taking a copy, then serializes them again. This has an > > appreciable effect of result latency so Fuseki takes the more optimistic > > approach of streaming them directly. > > > > Results are written to a ServletOutputStream in ResponseQuery (not the > > prettiest of code - it's heavily derived from Joseki and in Joseki that > > code goes back years). > > > > If you want them logged, you'd need to catch them: maybe implement a > > special ServletOutputStream that forks the byte stream, one stream to an > > underlying ServletOutputStream (the server body one) and one stream to > > the log. > > > > Andy > > > > > > On 19/05/11 18:44, Tim Harsch wrote: > > > Maybe usw the various Log Levels and let the configuration of SLF4J >handle > > >it. > > > For instance line 151 of SPARQL_ServletBase has: > > > > > > if ( response.message == null ) > > > serverlog.info(String.format("[%d] %d %s", id, > >response.statusCode, > > > HttpSC.getMessage(response.statusCode))) ; > > > else > > > serverlog.info(String.format("[%d] %d %s", id, > >response.statusCode, > > > response.message)) ; > > > > > > Is response.message what I'm looking for here? serverlog.trace() might >be > > >a > > > better level for that if it fills logs. I know you have to set the >verbose > > >flag > > > in order to get these messages in the first place. So maybe its good > > > as >it > > >is. > > > > > > Tim > > > > > > > > > > > > > > > ----- Original Message ---- > > >> From: Andy Seaborne<[email protected]> > > >> To: [email protected] > > >> Sent: Thu, May 19, 2011 1:05:49 AM > > >> Subject: Re: Fuseki server log > > >> > > >> No, not currently. > > >> > > >> I get them by poking the server with curl or wget. > > >> > > >> Another way of traffic watching would work. > > >> > > >> It might be useful to add the feature in some way but flooding the log > > >> file might not be the best way of doing it. Maybe writing to a > > >> directory or some such mechanism > > >> > > >> I can see a config file coming on. > > >> > > >> Andy > > >> > > >> On 18/05/11 18:46, Tim Harsch wrote: > > >>> Is there a way to get Fuseki to spit out response message? I want > > to > > see > > >> the > > >>> full text of the XML or JSON SPARQL result. > > >>> > > >>> Thanks, > > >>> Tim > > >>> > > >> > > >
