I did not raise bug in HttpClient project as it is not a bug, they just deprecated this constructor.
I'd be happy to not require updated HttpClient, but latest versions of Selenium require it. And I can't use old Selenium libs because of support for latest browsers. Andrey Pokhilko On 05/26/2015 09:29 PM, Philippe Mouawad wrote: > No objection for me. > Although having 3rd party plugins use different versions of dependencies > used by core exposes to issues and as such should be avoided. > > In this particular case , if we upgrade we should anyway update the code to > use the updated method. > > Did you raise a bug on HttpClient project ? > > Thanks > > > On Tuesday, May 26, 2015, Andrey Pokhilko <[email protected]> wrote: > >> Sebastian, >> >> I want to re-raise this topic again. >> >> The change is small and harmless, does not increase complexity, does not >> break any compatibilities. But it fixes compatibility with newer HT >> versions. >> >> Why you don't want to help people with custom plugins or libraries if it >> has no disadvantages? >> If your "I think..." is soft enough, may I commit this change, please? >> >> Andrey Pokhilko >> >> On 05/15/2015 03:06 PM, sebb wrote: >>> On 15 May 2015 at 12:41, Andrey Pokhilko <[email protected] <javascript:;>> >> wrote: >>>> It is not a bug in HC, they just deprecated that method since 4.3 and >>>> broke old behavior for deprecated method. >>> That's unfortunate, especially if it was not essential. >>> >>>> Even if we'll ask them to fix >>>> it and restore old behavior, they might say that we're using old version >>>> so to get the fix we'll need to upgrade our lib (which was already >>>> discussed and not likely to happen soon). >>> It might still be worth raising on the HC mailing list, as there are >>> likely other apps that are affected. >>> At the very least, the release notes ought to mention this behavioural >> change. >>> I think it is out of scope for JMeter to fix its code to support >>> non-standard versions of jars. >>> >>> This thread has documented at least two work-rounds that end-users can >> apply. >>>> Andrey Pokhilko >>>> >>>> On 05/15/2015 02:25 PM, sebb wrote: >>>>> On 15 May 2015 at 12:24, sebb <[email protected] <javascript:;>> wrote: >>>>>> Seems to me that this is not a bug in JMeter. >>>>>> >>>>>> It may perhaps be a bug in a later version of HttpComponents, but >>>>>> JMeter is not currently using that version. >>>>>> Before adding code to JMeter, I think we need to determine whether it >>>>>> is a bug in HC. >>>>>> >>>>>> I don't think we need to fix JMeter to support customised >> installations. >>>>>> Since JMeter is open source, the user can apply the fix for >> themselves. >>>>> Or indeed apply the fix to the HC mime code. >>>>> >>>>>> Once we have determined whether of not this is a bug in HC, we can >>>>>> determine whether or not JMeter needs to be updated when it is >>>>>> upgraded to the latest version of HC. >>>>>> >>>>>> >>>>>> >>>>>> On 15 May 2015 at 11:04, Andrey Pokhilko <[email protected] <javascript:;>> >> wrote: >>>>>>> Right. >>>>>>> >>>>>>> Andrey Pokhilko >>>>>>> >>>>>>> On 05/15/2015 12:55 PM, UBIK LOAD PACK Support wrote: >>>>>>>> AFAIU, setting name would not break existing behaviour and fix the >>>>>>>> situation right ? >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 15, 2015 at 11:50 AM, Andrey Pokhilko <[email protected] >> <javascript:;>> wrote: >>>>>>>>> I investigated it more. It happened that with stock httpmime-4.2.6 >> it >>>>>>>>> works, but user has upgraded HTTPComponents libraries to support >> custom >>>>>>>>> plugins. Since version 4.3 of httpmime they deprecated that >> constructor >>>>>>>>> and don't have automatic logic to set filename from file if >> filename is >>>>>>>>> null. >>>>>>>>> >>>>>>>>> This seems to be a deadlock situation for user unless we're making >> a >>>>>>>>> step towards custom plugin users and will call different >> super-constructor. >>>>>>>>> Sebb, what's your opinion? >>>>>>>>> >>>>>>>>> Andrey Pokhilko >>>>>>>>> >>>>>>>>> On 05/15/2015 12:05 AM, sebb wrote: >>>>>>>>>> OK, it does look like a bug, but according to the source for http >> mime >>>>>>>>>> 4.2.6 if filename is null it uses file.getName() anyway, so AFAICT >>>>>>>>>> your proposed fix would have no effect. >>>>>>>>>> >>>>>>>>>> This needs further investigation. >>>>>>>>>> >>>>>>>>>> On 14 May 2015 at 19:00, Andrey Pokhilko <[email protected] >> <javascript:;>> wrote: >>>>>>>>>>> Java implementation does well, providing required parameter: >>>>>>>>>>> >>>>>>>>>>> POST http://localhost/api/file/upload/ >>>>>>>>>>> >>>>>>>>>>> POST data: >>>>>>>>>>> -----------------------------7d159c1302d0y0 >>>>>>>>>>> Content-Disposition: form-data; name="jtl_file"; >>>>>>>>>>> *filename="011f07efb04762311137.jtl.gz" * >>>>>>>>>>> Content-Type: application/octet-stream >>>>>>>>>>> Content-Transfer-Encoding: binary >>>>>>>>>>> >>>>>>>>>>> <actual file content, not shown here> >>>>>>>>>>> -----------------------------7d159c1302d0y0-- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Andrey Pokhilko >>>>>>>>>>> >>>>>>>>>>> On 05/14/2015 07:57 PM, sebb wrote: >>>>>>>>>>>> On 14 May 2015 at 17:36, Andrey Pokhilko <[email protected] >> <javascript:;>> wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm trying to resolve a user issue when he claims that file >> upload >>>>>>>>>>>>> scenario is missing "filename" parameter. When I use >> HTTPClient4 I get >>>>>>>>>>>>> failing file upload request: >>>>>>>>>>>>> >>>>>>>>>>>>> POST http://localhost/api/file/upload/ >>>>>>>>>>>>> >>>>>>>>>>>>> POST data: >>>>>>>>>>>>> --cJfjtjR2_380MwSzTd_SQdQfG51aS5D >>>>>>>>>>>>> Content-Disposition: form-data; name="jtl_file"; >>>>>>>>>>>>> Content-Type: application/octet-stream >>>>>>>>>>>>> >>>>>>>>>>>>> <actual file content, not shown here> >>>>>>>>>>>>> --cJfjtjR2_380MwSzTd_SQdQfG51aS5D-- >>>>>>>>>>>>> >>>>>>>>>>>>> While for HTTPClient3.1 I have successful request with: >>>>>>>>>>>>> >>>>>>>>>>>>> POST http://localhost/api/file/upload/ >>>>>>>>>>>>> >>>>>>>>>>>>> POST data: >>>>>>>>>>>>> --wqkPl1L84AqGtph2Cgr79xYPJVMxntF4IJ >>>>>>>>>>>>> Content-Disposition: form-data; name="jtl_file"; >>>>>>>>>>>>> *filename="011f023437.jtl.gz" * >>>>>>>>>>>>> Content-Type: application/octet-stream >>>>>>>>>>>>> Content-Transfer-Encoding: binary >>>>>>>>>>>>> >>>>>>>>>>>>> <actual file content, not shown here> >>>>>>>>>>>>> --wqkPl1L84AqGtph2Cgr79xYPJVMxntF4IJ-- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> After digging into HTTPClient4 implementation I found that >> we're >>>>>>>>> really >>>>>>>>>>>>> do not pass filename parameter to underlying http library. >> This is >>>>>>>>> easy >>>>>>>>>>>>> to fix by changing this line: >>>>>>>>>>>>> >> https://github.com/apache/jmeter/blob/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPHC4Impl.java#L966 >>>>>>>>>>>>> from >>>>>>>>>>>>> >>>>>>>>>>>>> super(file, mimeType); >>>>>>>>>>>>> >>>>>>>>>>>>> into: >>>>>>>>>>>>> >>>>>>>>>>>>> super(file, file.getName(), mimeType, null); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Questions: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Is that a bug? Maybe a known one? Or this is intended >> behavior. >>>>>>>>>>>> It would be useful to know what the Java implementation does. >>>>>>>>>>>> >>>>>>>>>>>>> 2. Should I fix this as demonstrated (if this is a bug)? >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Andrey Pokhilko >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>
