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.moua...@gmail.com> wrote: > > > On Tue, Oct 11, 2011 at 2:38 PM, sebb <seb...@gmail.com> wrote: > >> On 9 October 2011 10:41, Philippe Mouawad <philippe.moua...@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 <seb...@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-unsubscr...@jakarta.apache.org >> >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> >> >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> > > > -- > Cordialement. > Philippe Mouawad. > > > > -- Cordialement. Philippe Mouawad.