Mailing-List: contact dev-help@jmeter.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jmeter.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CABWbpFcUd-FBwbMGwRdLn1p=pgRRePNuDjqdWgh+o=_Je2Lj6Q@mail.gmail.com>
References: 
 <CAH9fUpb+H8k2pHVGb9-sJ3i+O5oEwQbsh0gD=tZ72VdnR9dGPQ@mail.gmail.com>
	<CABWbpFcUd-FBwbMGwRdLn1p=pgRRePNuDjqdWgh+o=_Je2Lj6Q@mail.gmail.com>
Date: Fri, 18 Mar 2016 22:30:37 +0100
Message-ID: 
 <CAH9fUpZt6K_vrz__ihO2Dwc0VRcrHAtGux1E3ML5zRC1Fai24g@mail.gmail.com>
Subject: Re: Deprecate Java Implementation in HTTP Request before dropping it
 in N+2 version ?
From: Philippe Mouawad <philippe.mouawad@gmail.com>
To: "dev@jmeter.apache.org" <dev@jmeter.apache.org>
Content-Type: multipart/alternative; boundary=001a113b38703e69a8052e597591

--001a113b38703e69a8052e597591
Content-Type: text/plain; charset=UTF-8

Hello,
Any thoughts on this one ?

Some additional reasons:

   - What is the RFC supported ? With HttpClient we support RFC2616, which
   one do we support with Java when we delegate Redirection management to it ?

Thanks

On Sun, Mar 6, 2016 at 12:30 PM, Antonio Gomes Rodrigues <ra0077@gmail.com>
wrote:

> Hi,
>
> I never have to use Java implementation
>
> If HC3 and Java implementation are deprecated it will be great to remove it
> from GUI (and use only the propertie in jmeter.propertie)
>
> It will allow to:
> Don't disturb new comers with this choice
> Simplify the GUI
> Don't disturb user who don't care before
> Advanded user who have the need of it have still the choice (in the
> propertie file) before the remove of the feature
>
> Antonio
>
> 2016-03-05 0:45 GMT+01:00 Philippe Mouawad <philippe.mouawad@gmail.com>:
>
> > Hello,
> > What do you think of dropping Java Implementation in 3.1 version ?
> >
> > I see many issues in keeping it:
> >
> >    - More work to maintain Http Request
> >    - Algorithm complexity to handle this additional implementation
> >    - The implementation is very limited compared to HC4 (it appears only
> >    GET/POST/PUT are supported in our implementation)
> >    - Features of HttpHC4Implementation are not supported, so it can be
> >    disturbing when you switch between implementation that you lose some
> >    feature:
> >       - It does not support the following methods: COPY, LOCK, MKCOL,
> MOVE,
> >       PATCH, PROPFIND, PROPPATCH, UNLOCK, REPORT, MKCALENDAR.
> >       - It does not support Kerberos Auth
> >       - https.use.cached.ssl.context
> >       - There is no control over how connections are re-used. When a
> >       connection is released by JMeter, it may or may not be re-used
> > by the same
> >       thread.
> >       - The API is best suited to single-threaded usage - various
> settings
> >       are defined via system properties, and therefore apply to all
> > connections.
> >       - There is a bug in the handling of HTTPS via a Proxy (the CONNECT
> is
> >       not handled correctly). See Java bugs 6226610 and 6208335.
> >       - It does not support virtual hosts.
> >       - It does not support client based certificate testing with
> Keystore
> >       Config.
> >       - Digest Auth
> >
> > In my experience there is only one case I see where it was useful
> > ,sometimes recording fails and only Java Impl is able to record:
> >
> >    - I think bug is https://bz.apache.org/bugzilla/show_bug.cgi?id=59101
> .
> >
> >
> > So maybe we should deprecate it in 3.0 and ask users who are facing
> issues
> > with HC4 to report any problem.
> >
> > If nothing is reported we disable it in 3.1 (make it possible to enable
> it
> > by a property) and drop it in 3.2.
> > Regards
> > Philippe
> >
>


-- 
Cordialement.
Philippe Mouawad.

--001a113b38703e69a8052e597591--