jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Bug 52728 - CSV Dataset and BSF Sampler; how to handle ConfigTestElements
Date Tue, 03 Apr 2012 21:08:41 GMT
Hello,
I think implementing this will fix following issues:

   - https://issues.apache.org/bugzilla/show_bug.cgi?id=53027
   - https://issues.apache.org/bugzilla/show_bug.cgi?id=50799

Regards

Philippe

On Sun, Feb 26, 2012 at 2:56 PM, Philippe Mouawad <
philippe.mouawad@gmail.com> wrote:

> I agree, although reading again my sentence I see it's not clear.
>
> If a new ConfigElement is added then there is not need that existing
> sampler accept it,while the reverse is true.
> So the master if the sampler not the config element.
>
>
>
>
>
> On Sun, Feb 26, 2012 at 1:52 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 26 February 2012 10:01, Philippe Mouawad <philippe.mouawad@gmail.com>
>> wrote:
>> > Very good idea.
>> > I would rather go for a method to determine if a config element applies
>> to
>> > Sampler.
>>
>> Thinking further about this:
>>
>> A single config element applies to many samplers; add a new sampler
>> and it may re-use the same config element (with different GUI).
>> So I think it must be the sampler that has a method to check if the
>> config element applies or not, based on the config class and GUI
>> class.
>>
>> We need to ensure that any change does not stop 3rd party samplers
>> (and config elements) from working.
>>
>> One way might be to add a new interface to define the method; samplers
>> that want to restrict which config elements apply to them would need
>> to implement the method.
>>
>> There could be a default implementation in AbstractSampler that
>> accepted all config elements (to retain backward compat).
>>
>> I think this would be OK for 3rd party samplers, except for the case
>> where a sampler extended an existing JMeter sampler, and also had its
>> own config element.
>>
>> Or are there any other cases that might be affected?
>>
>> Another possible approach might be for samplers to register which
>> config elements apply to them; this would be a bit harder to code -
>> and might not be efficient enough - but would potentially allow for
>> customisation (e.g. using properties) when starting JMeter. This would
>> allow overrides for 3rd party samplers.
>>
>> Or maybe somehow combine the two: before finally rejecting the config
>> element, a sampler checks for any overrides that have been registered.
>>
>> As a fallback, we could/should use a property to disable the config
>> element filtering, in case it turns out to have unwanted side-effects.
>>
>> > Regards
>> > Philippe
>> >
>> > On Thu, Feb 23, 2012 at 11:48 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> The proposed patch works by skipping CSVDataSet when merging in the
>> >> configuration elements.
>> >>
>> >> ConfigTestElements have to be merged into samplers, in order that the
>> >> samplers can pick up the configuration elements that apply to them.
>> >>
>> >> This means that all samplers are provided with all the data from every
>> >> config element in scope. This was perhaps OK initially, when there
>> >> weren't many samplers, but now there are lots of samplers and lots of
>> >> config elements.
>> >>
>> >> Duplication of names is now more difficult to avoid, and there is more
>> >> wasted space; each sampler only needs the settings from some of the
>> >> config elements.
>> >>
>> >> It would be nice if there were a method on the config element that
>> >> specified which samplers it applied to - or equally, if samplers had a
>> >> method to determine if a config element applied to them.
>> >>
>> >> However, I don't know if there is an easy way to determine which
>> >> config elements apply to which samplers.
>> >>
>> >> Some specific configs are obvious, such as CSVDataSet, which is not
>> >> directly associated with any Sampler. The same probably applies to
>> >> RandomVariableConfig.
>> >>
>> >> AuthManager, CookieManager etc only apply to HTTP samplers.
>> >>
>> >> But there are a lot of sampler configurations that use the basic
>> >> ConfigTestElement; I suppose it might be possible to use the
>> >> TestElement.gui_class String property.
>> >>
>> >> This needs a bit more thought...
>> >>
>> >
>> >
>> >
>> > --
>> > Cordialement.
>> > Philippe Mouawad.
>>
>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message