Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4492E9AD.5080106@dubioso.net>
Date: Fri, 16 Jun 2006 19:26:05 +0200
From: Roland Weber <http-async@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060428
MIME-Version: 1.0
To: HttpClient Project <httpclient-dev@jakarta.apache.org>
Subject: [HttpAsync][log] How to implement logging?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi folks,

I have spent some time over the last weeks thinking about how
to implement logging in HttpAsync. The approach to do all
logging through loggers based on class names has significant
limitations when you have multiple users of HttpClient in the
JVM and want to configure logging independently. We've discussed
that a few years back and came up with a workaround based on
thread-local settings. (I'm glad I haven't had to implement
that yet :-) With HttpAsync using background threads, that
workaround is no longer an option.
After that, I've thought about passing a request and/or
dispatcher specific loggers through HttpContext, and using the
class based logger names only as a fallback. Some reading of
the commons-logging documentation, including this wiki page:
http://wiki.apache.org/jakarta-commons/Logging/StaticLog
and more thinking convinced me that class based logger names
are just pointless for our purposes.
In my experience, they are mostly used on package levels anyway,
to enable or disable logging from some parts of a large
application or framework. Although it is also possible to
reduce the logging noise by enabling logging only for some
classes, that feature was never actually used for HttpClient
on the mailing list. So I doubt we'll miss it in the future.

In summary, here is my suggestion for implementing logging
in the HttpAsync component:

- HttpAsync uses o.a.c.l.Log objects, but *never* creates
  them. It does not use o.a.c.l.LogFactory.
- o.a.c.l.Log objects are passed through HttpContext from
  the application to HttpAsync.
- There will be a small choice of logging types, for which
  different (or identical) loggers can be passed. This allows
  for logging to different targets (files) for each type.
- Type A: request specific information. Like preprocessing,
  starting to send the request, waiting for the response,
  receiving the response header, and so on.
- Type B: cross-request information from dispatchers. Like
  the number of requests/handles in queues, connection use,
  thread state changes, and so on.
- No other types for now.
- The lookup names for logger types in the HttpContext can
  be parameterized. This allows applications to either set
  loggers in the HttpContext with the default names, or to
  put the loggers in the default context with application
  specific names and activate them per request through params.

With this approach, we're not going to have any classloader
or other logging configuration issues within HttpAsync, or
other components that adopt the same approach. On the down
side, it requires a little more effort from application
developers to activate logging than just setting a property
or two.

This approach should be equally suitable for HttpClient 4.0.
The suitability ends where the HttpContext is no longer
available: at the connection. Which makes me wonder whether
we should pass the HttpContext down to the connection and
transmitter as well. If we did that, we could replace the
header parsing currently done for the transfer encoding
with a lookup in the HttpContext. But that's just an idea
in it's early stages and still needs to be thought through.

Please let me know what you think.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org