r1293562 > JMeter 2.6

Enhancement based on Sebb idea on mailing list:


Philippe Mouawad 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  wrote:

    On 26 February 2012 10:01, Philippe Mouawad  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  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...
    >>
    >
    >