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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > > -- Cordialement. Philippe Mouawad.
