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