> > Also, in my view, the lifecycle interfaces defined in the > > Avalon framework may or may not be useful as is to JMeter. > > I'm currently thinking that JMeter may want to define it's > > own lifecycle interfaces (for instance, there are two > > separate times when JMeter clones test objects - once for > > each thread, and once for each individual sample request. > > However, for many objects, these two cloning events are > > unneccessary, and for others, both are necessary, and for > > still others, only one of the other are necessry. These > > could be two lifecycle interfaces that developers would > > choose to implement or not, thus defining the behavior for > > their extension). > > I would encourage the use of predefined lifecycle interfaces > and the configuration/parameters objects as they make life > simpler when you want to use the same component outside of > JMeter. You don't need to use all of them, but they are there > if you need it. They are called in a defined order, and keeping > that order consistent across projects helps make it easier > to learn a new system.
The problem I have with the predefined lifecycle interfaces of Avalon is that many of them use typeless data objects. Configuration, for instance, passes DOM trees around. Why is it preferable to pass data as DOM trees rather than as normal Java Objects? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
