Bug 52728 - CSV Dataset and BSF Sampler; how to handle ConfigTestElements

[sebb <se...@gmail.com>]

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...

Re: Bug 52728 - CSV Dataset and BSF Sampler; how to handle ConfigTestElements

[Philippe Mouawad <ph...@gmail.com>]

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 <se...@gmail.com> wrote:
>
>> On 26 February 2012 10:01, Philippe Mouawad <ph...@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 <se...@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.

Re: Bug 52728 - CSV Dataset and BSF Sampler; how to handle ConfigTestElements

[Philippe Mouawad <ph...@gmail.com>]

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 <se...@gmail.com> wrote:

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

Re: Bug 52728 - CSV Dataset and BSF Sampler; how to handle ConfigTestElements

[sebb <se...@gmail.com>]

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

Re: Bug 52728 - CSV Dataset and BSF Sampler; how to handle ConfigTestElements

[Philippe Mouawad <ph...@gmail.com>]

Very good idea.
I would rather go for a method to determine if a config element applies to
Sampler.

Regards
Philippe

On Thu, Feb 23, 2012 at 11:48 PM, sebb <se...@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.