Hi, Mike.
All things considered, I'm inclined to agree. And it's not creating a
problem for me at the moment. My NullSampler.sample(Entry) just returns
null, but I wonder if I'll have to modify that when I start plugging in
listeners.
However, since I've invested a little time on this issue, I'll toss in
my .08 bits ($0.02). (Hope you don't mind.) A package like JMeter
should be safely extensible; it shouldn't have to "learn about this new
possibility". Documenting and adhering to the contracts of the various
framework classes would go a long way. Implementing the contracts in
the framework classes, then closing those classes for modification while
leaving them open for extension, would be even better. There seems to
be a lot of procedural tangling up and down the inheritance hierarchies;
it's better to ask "What is this thing I'm coding?" than "How can I
modify this thing to do what I want?" O-O programming is descriptive,
procedural programming is prescriptive.
Ok, sorry, no more unsolicited advice about Object Zen.
I hate to suggest another big mod to the framework classes. I know the
last one broke a lot of user code. (Entry?) But I'm itching to do it
now that I've done the research, you know how that goes. If you ever
consider such a thing, let me know and I'll contribute what I can. On
the other hand, if you're pretty sure the framework is locked down, I
could contribute some up-to-date howto's for controllers and samplers.
I've got to write them anyway for my coders at work.
jp
public class NullSampler extends AbstractSampler {
private static NullSampler instance;
private NullSampler() {
}
public static synchronized NullSampler getInstance() {
if (instance == null) {
instance = new NullSampler();
}
return instance;
}
public SampleResult sample(Entry e) {
return null;
}
}
On Sun, 2004-01-25 at 13:07, [EMAIL PROTECTED] wrote:
> Ok, so here's the thing. If you have a controller that does nothing but return
> null, a loop
> controller is going to continue searching for a sub-controller with a sampler to
> return. If you're
> controller returned a sampler, then null, then a sampler, then null, etc (like a
> normal controller
> does),
what's a "normal controller"?
then this problem doesn't show up. It's when you have a sampler that insists on never
> providing a sampler, yet also insists it's got samplers to provide (ie, it's not
> "done").
>
> So, here you are trying to make a triggered controller that could reasonably have no
> samplers
> to provide, but insists that it might at some point in the future. It's sort of a
> new situation not
> anticipated by the current code. You could create a NullSampler that returns a
> dummy
> ResponseData object to get around this, though that's a substandard solution since
> your
> listeners will get a lot of these things. But, I'm not sure I see a better solution
> until JMeter
> learns about this new possibility.
>
> -Mike
>
> On 24 Jan 2004 at 16:00, Jerry Pulley wrote:
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
