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 Sun, 26 Feb 2012 13:56:18 GMT
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.

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