There are several ways around this Java restriction. The one that strikes me at the moment is to provide a "WireLogFactory" class. It would reside in the same package as WireLogInputStream and WireLogOutputStream, and thus allow those classes to be package protected, not public. It needs at least two functions, maybeLogInputStream(), and maybeLogOutputStream().
This would also give us one place to centralize the logic that says:
if (WIRE_LOG.isDebugEnabled()) {
is = new WireLogInputStream(is);
}
Instead you could write something like this:
is = WireLogFactory.maybeLogInputStream(is);
thus eliminating the need for all parts of the code interesting in wire logging from having to be aware of how the logging gets triggered.
With a slight extension, you could set the actual category for logging to be a static, but not final variable, and then provide a means for clients to set that value. In that way, if the client wanted to set the "logging" category for wire logging to something different - they could do so.
Just some ideas.
-Eric.
Oleg Kalnichevski wrote:
Jeff,
Wire, WireLogOutputStream, WireLogInputStream classes need to be
accessible by classes from the following packages:
org.apache.commons.httpclient
org.apache.commons.httpclient.methods
org.apache.commons.httpclient.methods.multipart
Making wire logging related classes non-public does not seem feasible
with the present package structure.
Cheers
Oleg
On Tue, 2003-02-11 at 04:19, Jeffrey Dever wrote:
I like the refactoring. Only complaint is that the classes are public. Package access would be prefered, but this may not be possible.
Oleg Kalnichevski wrote:
Fixes the following bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14782
Change log:
- MultipartPost related methods clean-up
- Part#send(OutputStream out) & long Part#length() are no more final
- Content encoding can be specified - FilePart's content type can be specified - FilePart's transfer encoding can be specified - Wire logging improvement
While working on multi-part post stuff I have been through many pains
debugging modified classes and trying to figure out what exactly gets
sent to the server. Currently wire logging can be regarded as
inconsistent at best. In those parts where wire logging is implemented I
find it not particularly visually appealing. While "scratching my own
itch" I have taken liberty of rewriting wire logging. Please comment if
you find these changes acceptable. Suggestions on possible improvements
are welcome.
To be done next:
- Fix bug #14036
- Apply new wire logging consistently throughout the HttpClient codebase
(provided new wire logging meets your approval)
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
