No, it doesn't matter for this particular instance. It is a special case however, and in general, it's certainly safer to clone deeply for your own controllers.
The reason it's ok is that all elements are cloned when they are submitted into Entry objects (see org.apache.jmeter.samplers.Entry(addConfigElement()). You'll notice that ConfigElements are usually cloned as they enter a sample - this is to allow the sampling process to modify itself without affecting the source information. However, if any config element returned "true" from the expectsModification() method, it should be cloned when the script is compiled and sent to the JMeter Engine. -Mike > -----Original Message----- > From: Paul Glezen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 01, 2001 4:51 PM > To: [EMAIL PROTECTED] > Subject: Clone on Generative Controller > > > Sorry if this is a duplicate. I sent it to the jmeter-dev > list a couple > days ago (during the move of the mailing list servers) and > have yet to see > it materialize in the archives. > > I'm attempting to write my own generative controller using > existing ones as > examples. The clone method of > org.apache.jmeter.protocol.http.control.HttpTestSample has the clone > instance sharing the same UrlConfig object as the original > HttpTestSample > instance. Is there something about the JMeter framework that > makes this > behaviour desirable/acceptable? Or should the clone method > of UrlConfig be > invoked to acquire a cloned config object for the cloned > controller object? > > Thanks for any guidance, > - Paul > > Paul Glezen > Consulting IT Specialist > IBM Software Services for WebSphere > 818 539 3321 > > > > -- > To unsubscribe, e-mail: > <mailto:jmeter-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
