You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jakarta.apache.org by sebb <se...@gmail.com> on 2011/09/28 16:52:41 UTC
[JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
If HttpDefaults and HttpRequest both use Parameters, then the body is
created from both sets of parameters.
When the body is being built, if any of the parameters have names,
only named parameters are kept.
Any unnamed parameters are ignored.
It's not possible to mix named and unnamed parameters; named
parameters take precedence.
If both test elements have unnamed variables only, then the body is
created from the merging of the two sets of values.
That is existing behaviour, and cannot be changed without potentially
affecting users.
Now the raw body option is currently handled as an un-named parameter.
This means that the a Raw HTTP Request will be ignored if there is a
named default parameter, and unnamed default parameters will be
appended to the body.
That does not seem right; I would expect the raw option to provide the
complete body.
This will mean a change to the way defaults are handled.
I think this needs more discussion.
It could take a while to resolve the issues and debug the code, so I
think it will have to wait for a later version of JMeter; I've held up
the current one long enough!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Sebb,
I submitted a new version of patch that takes into account the folliwing:
- if the raw flag is set, we don't do a merge; otherwise keep current
behaviour (I noticed that if there is only one parameter in request with no
name and there are parameters in request default, only parameters of
Request Defaults are passed)
- Request Defaults doesn't contain Raw Body Tabbed Pane
- I use a new JMX boolean attribute to store wether raw body is used or
not
I didn't use a new Attribute to store Raw Body data (to ease switching) ,
because I think using it would introduce new questions:
- what to do with old table parameters when raw body is selected and a
save occurs ?
- We Would have 2 different sets of data , but what's the relation with
them ?
Maybe I didn't understand what you meant by it.
Regarding common code between HC3, HC4, Java impl, I didn't change this
because it is risky for me and could introduce regressions (although I agree
with you this should be tackled some day) and
it was not needed to implement this feature.
I am waiting for your go to either commit or do some other changes.
Regards
Philippe
On Sat, Oct 15, 2011 at 6:58 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:
>
>
> On Tue, Oct 11, 2011 at 2:38 PM, sebb <se...@gmail.com> wrote:
>
>> On 9 October 2011 10:41, Philippe Mouawad <ph...@gmail.com>
>> wrote:
>> > Hello Sebb,
>> > Regarding this, if we add a checkbox in Request Sampler GUI to indicate
>> to
>> > user that merge will occur on request.
>> > This would be checked by default unless user switches to RAW body, if
>> switch
>> > is accepted, checkbox is unchecked
>> >
>> > So we would have this behaviour:
>> >
>> > - RAW body used, no merge
>> > - Post Parameter , merge occurs
>> >
>> >
>> > What's your opinion, do you see other issues ?
>>
>> I'm not sure I want to see yet another checkbox on that screen.
>> Seems to me we should try to use the raw body flag to control the
>> behaviour.
>>
>> OK
>
>> So if the raw flag is set, we don't do a merge; otherwise keep current
>> behaviour.
>>
>> OK
>
>> I think we should probably disable the raw option entirely for Http
>> Defaults, otherwise I think it will be treated as an unnamed parameter
>> and merged with any non-raw samplers. That would be quite confusing.
>>
>> OK , I will add it to patch .
> Should it be a boolean in UrlConfigGUI or another class ? (First solution
> is simple)
>
> Another possibility would be to use a separate JMX attribute for the
>> raw body (default omitted if empty).
>> This would make switching easier, as the panes would not share storage
>> areas.
>>
>> OK, will add it to patch
>
>> Also need to look at whether the samplers can share common code for
>> generating the request body.
>> We need to look at that whether or not we use a separate JMX
>> atttribute, because that is where any merging is done currently.
>>
>> The samples currently use
>> HTTPSamplerBase.getSendParameterValuesAsPostBody() to check if the
>> request body is being generated from param values.
>>
>> Perhaps the first stage should be to try to extract all the common
>> code that builds the body and move that into the parent class.
>>
>> > Thanks
>> >
>> > Regards
>> > Philippe
>> >
>> > On Wed, Sep 28, 2011 at 4:52 PM, sebb <se...@gmail.com> wrote:
>> >
>> >> If HttpDefaults and HttpRequest both use Parameters, then the body is
>> >> created from both sets of parameters.
>> >>
>> >> When the body is being built, if any of the parameters have names,
>> >> only named parameters are kept.
>> >> Any unnamed parameters are ignored.
>> >> It's not possible to mix named and unnamed parameters; named
>> >> parameters take precedence.
>> >>
>> >> If both test elements have unnamed variables only, then the body is
>> >> created from the merging of the two sets of values.
>> >>
>> >> That is existing behaviour, and cannot be changed without potentially
>> >> affecting users.
>> >>
>> >> Now the raw body option is currently handled as an un-named parameter.
>> >> This means that the a Raw HTTP Request will be ignored if there is a
>> >> named default parameter, and unnamed default parameters will be
>> >> appended to the body.
>> >>
>> >> That does not seem right; I would expect the raw option to provide the
>> >> complete body.
>> >>
>> >> This will mean a change to the way defaults are handled.
>> >>
>> >> I think this needs more discussion.
>> >>
>> >> It could take a while to resolve the issues and debug the code, so I
>> >> think it will have to wait for a later version of JMeter; I've held up
>> >> the current one long enough!
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: dev-help@jakarta.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>
--
Cordialement.
Philippe Mouawad.
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
Posted by Philippe Mouawad <ph...@gmail.com>.
On Tue, Oct 11, 2011 at 2:38 PM, sebb <se...@gmail.com> wrote:
> On 9 October 2011 10:41, Philippe Mouawad <ph...@gmail.com>
> wrote:
> > Hello Sebb,
> > Regarding this, if we add a checkbox in Request Sampler GUI to indicate
> to
> > user that merge will occur on request.
> > This would be checked by default unless user switches to RAW body, if
> switch
> > is accepted, checkbox is unchecked
> >
> > So we would have this behaviour:
> >
> > - RAW body used, no merge
> > - Post Parameter , merge occurs
> >
> >
> > What's your opinion, do you see other issues ?
>
> I'm not sure I want to see yet another checkbox on that screen.
> Seems to me we should try to use the raw body flag to control the
> behaviour.
>
> OK
> So if the raw flag is set, we don't do a merge; otherwise keep current
> behaviour.
>
> OK
> I think we should probably disable the raw option entirely for Http
> Defaults, otherwise I think it will be treated as an unnamed parameter
> and merged with any non-raw samplers. That would be quite confusing.
>
> OK , I will add it to patch .
Should it be a boolean in UrlConfigGUI or another class ? (First solution is
simple)
Another possibility would be to use a separate JMX attribute for the
> raw body (default omitted if empty).
> This would make switching easier, as the panes would not share storage
> areas.
>
> OK, will add it to patch
> Also need to look at whether the samplers can share common code for
> generating the request body.
> We need to look at that whether or not we use a separate JMX
> atttribute, because that is where any merging is done currently.
>
> The samples currently use
> HTTPSamplerBase.getSendParameterValuesAsPostBody() to check if the
> request body is being generated from param values.
>
> Perhaps the first stage should be to try to extract all the common
> code that builds the body and move that into the parent class.
>
> > Thanks
> >
> > Regards
> > Philippe
> >
> > On Wed, Sep 28, 2011 at 4:52 PM, sebb <se...@gmail.com> wrote:
> >
> >> If HttpDefaults and HttpRequest both use Parameters, then the body is
> >> created from both sets of parameters.
> >>
> >> When the body is being built, if any of the parameters have names,
> >> only named parameters are kept.
> >> Any unnamed parameters are ignored.
> >> It's not possible to mix named and unnamed parameters; named
> >> parameters take precedence.
> >>
> >> If both test elements have unnamed variables only, then the body is
> >> created from the merging of the two sets of values.
> >>
> >> That is existing behaviour, and cannot be changed without potentially
> >> affecting users.
> >>
> >> Now the raw body option is currently handled as an un-named parameter.
> >> This means that the a Raw HTTP Request will be ignored if there is a
> >> named default parameter, and unnamed default parameters will be
> >> appended to the body.
> >>
> >> That does not seem right; I would expect the raw option to provide the
> >> complete body.
> >>
> >> This will mean a change to the way defaults are handled.
> >>
> >> I think this needs more discussion.
> >>
> >> It could take a while to resolve the issues and debug the code, so I
> >> think it will have to wait for a later version of JMeter; I've held up
> >> the current one long enough!
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
Posted by sebb <se...@gmail.com>.
On 9 October 2011 10:41, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello Sebb,
> Regarding this, if we add a checkbox in Request Sampler GUI to indicate to
> user that merge will occur on request.
> This would be checked by default unless user switches to RAW body, if switch
> is accepted, checkbox is unchecked
>
> So we would have this behaviour:
>
> - RAW body used, no merge
> - Post Parameter , merge occurs
>
>
> What's your opinion, do you see other issues ?
I'm not sure I want to see yet another checkbox on that screen.
Seems to me we should try to use the raw body flag to control the behaviour.
So if the raw flag is set, we don't do a merge; otherwise keep current
behaviour.
I think we should probably disable the raw option entirely for Http
Defaults, otherwise I think it will be treated as an unnamed parameter
and merged with any non-raw samplers. That would be quite confusing.
Another possibility would be to use a separate JMX attribute for the
raw body (default omitted if empty).
This would make switching easier, as the panes would not share storage areas.
Also need to look at whether the samplers can share common code for
generating the request body.
We need to look at that whether or not we use a separate JMX
atttribute, because that is where any merging is done currently.
The samples currently use
HTTPSamplerBase.getSendParameterValuesAsPostBody() to check if the
request body is being generated from param values.
Perhaps the first stage should be to try to extract all the common
code that builds the body and move that into the parent class.
> Thanks
>
> Regards
> Philippe
>
> On Wed, Sep 28, 2011 at 4:52 PM, sebb <se...@gmail.com> wrote:
>
>> If HttpDefaults and HttpRequest both use Parameters, then the body is
>> created from both sets of parameters.
>>
>> When the body is being built, if any of the parameters have names,
>> only named parameters are kept.
>> Any unnamed parameters are ignored.
>> It's not possible to mix named and unnamed parameters; named
>> parameters take precedence.
>>
>> If both test elements have unnamed variables only, then the body is
>> created from the merging of the two sets of values.
>>
>> That is existing behaviour, and cannot be changed without potentially
>> affecting users.
>>
>> Now the raw body option is currently handled as an un-named parameter.
>> This means that the a Raw HTTP Request will be ignored if there is a
>> named default parameter, and unnamed default parameters will be
>> appended to the body.
>>
>> That does not seem right; I would expect the raw option to provide the
>> complete body.
>>
>> This will mean a change to the way defaults are handled.
>>
>> I think this needs more discussion.
>>
>> It could take a while to resolve the issues and debug the code, so I
>> think it will have to wait for a later version of JMeter; I've held up
>> the current one long enough!
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: dev-help@jakarta.apache.org
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Sebb,
Regarding this, if we add a checkbox in Request Sampler GUI to indicate to
user that merge will occur on request.
This would be checked by default unless user switches to RAW body, if switch
is accepted, checkbox is unchecked
So we would have this behaviour:
- RAW body used, no merge
- Post Parameter , merge occurs
What's your opinion, do you see other issues ?
Thanks
Regards
Philippe
On Wed, Sep 28, 2011 at 4:52 PM, sebb <se...@gmail.com> wrote:
> If HttpDefaults and HttpRequest both use Parameters, then the body is
> created from both sets of parameters.
>
> When the body is being built, if any of the parameters have names,
> only named parameters are kept.
> Any unnamed parameters are ignored.
> It's not possible to mix named and unnamed parameters; named
> parameters take precedence.
>
> If both test elements have unnamed variables only, then the body is
> created from the merging of the two sets of values.
>
> That is existing behaviour, and cannot be changed without potentially
> affecting users.
>
> Now the raw body option is currently handled as an un-named parameter.
> This means that the a Raw HTTP Request will be ignored if there is a
> named default parameter, and unnamed default parameters will be
> appended to the body.
>
> That does not seem right; I would expect the raw option to provide the
> complete body.
>
> This will mean a change to the way defaults are handled.
>
> I think this needs more discussion.
>
> It could take a while to resolve the issues and debug the code, so I
> think it will have to wait for a later version of JMeter; I've held up
> the current one long enough!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
Posted by sebb <se...@gmail.com>.
On 28 September 2011 19:59, Philippe Mouawad <ph...@gmail.com> wrote:
> Hello Sebb,
> Thanks for the analysis.
> I agree with you and will try to handle these cases, do you prefer a
> discussion in mailing list or in issue ?
Mailing list.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org
Re: [JMeter] Issue 51861 - Improve HTTP Request GUI to better show
parameters without name (Raw Body)
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello Sebb,
Thanks for the analysis.
I agree with you and will try to handle these cases, do you prefer a
discussion in mailing list or in issue ?
No problem for me if it is not taken into account in this release provided
it is in next or not too far in the future so that patches are still valid
:-)
Regards
Philippe
On Wed, Sep 28, 2011 at 4:52 PM, sebb <se...@gmail.com> wrote:
> If HttpDefaults and HttpRequest both use Parameters, then the body is
> created from both sets of parameters.
>
> When the body is being built, if any of the parameters have names,
> only named parameters are kept.
> Any unnamed parameters are ignored.
> It's not possible to mix named and unnamed parameters; named
> parameters take precedence.
>
> If both test elements have unnamed variables only, then the body is
> created from the merging of the two sets of values.
>
> That is existing behaviour, and cannot be changed without potentially
> affecting users.
>
> Now the raw body option is currently handled as an un-named parameter.
> This means that the a Raw HTTP Request will be ignored if there is a
> named default parameter, and unnamed default parameters will be
> appended to the body.
>
> That does not seem right; I would expect the raw option to provide the
> complete body.
>
> This will mean a change to the way defaults are handled.
>
> I think this needs more discussion.
>
> It could take a while to resolve the issues and debug the code, so I
> think it will have to wait for a later version of JMeter; I've held up
> the current one long enough!
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
--
Cordialement.
Philippe Mouawad.
Ubik-Ingénierie