Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Subject: Re: [PATCH] MultipartPost revisited (take 1)
From: Oleg Kalnichevski <o.kalnichevski@dplanet.ch>
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
In-Reply-To: <3E4906C2.5090005@tibco.com>
References: <1044916212.1521.54.camel@kczrh-okt22.corp.bearingpoint.com>
	 <3E486BD6.6050609@sympatico.ca>
	 <1044967052.15380.5.camel@kczrh-okt22.corp.bearingpoint.com>
	 <3E4906C2.5090005@tibco.com>
Content-Type: text/plain
Organization: 
Message-Id: <1044979044.15380.29.camel@kczrh-okt22.corp.bearingpoint.com>
Mime-Version: 1.0
Date: 11 Feb 2003 16:57:24 +0100
Content-Transfer-Encoding: 7bit

Eric

The factory pattern appears well applicable were. However, I am not
entirely sure the Wire class should be invisible to the classes outside
org.apache.commons.httpclient package. I'll toy around with different
scenarios and post the second take of the patch for your review
Cheers

Oleg 


On Tue, 2003-02-11 at 15:20, Eric Johnson wrote:
> Oleg,
> 
> 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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>