> -----Original Message----- > From: Stover, Michael [mailto:[EMAIL PROTECTED]] > > I'm wondering if we're disagreeing over a difference of > context. I understand that when you say "Component", you do > not mean the same thing that I mean when I think it. You, I > think, are referring to something much more active, almost a > service type of thing. Whereas, what I am thinking of, you > would call merely "data".
Aha! Data != Component. Components should *do*, not represent. It is best to separate the terms in our minds so we don't run into this confusion all the time. > However, what I'm seeing is that the idea of Component > lifecycle can be applied beyond just your idea of Components. > The test elements of JMeter may not be full-fledged > Components, but they nevertheless go through a well-defined > lifecycle, and I am beginning to see how some of the design > ideas of Avalon can help even there. Perhaps that makes more sense? That does make sense, but for the Components (the *doers*) we should use standard interfaces. Once the configuration data is built, we should make it static while the test engine is running. That way it can be referred to without need for synchronization (nothing changes) to help with scalability. But please do heed my warning about fragile serialization. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
