I agree it's still a useful thing to have. It provides a simple way for people to link in their jdbc drivers and java sampler targets without having to copy/paste them into jmeter's home directories, and without having to deal with JMeter's classpath madness.
-Mike On Wed, 2005-09-21 at 13:32 -0400, Peter Lin wrote: > I've finally figured out the classloader issue. The basic summary is this. > > 1. since the TestElements are loaded in the main Classloader, it references > the main CL > 2. it doesn't matter if I create a new CL and set each thread to use it, > since the class was already loaded. Is there a way to unload a Class? I > can't think of an easy way off hand > > I've settled on setting the classpath in the main classloader. That works as > expected and allows users to define additional classpaths. the downside is > that if the classpaths change, users have to restart JMeter. If an user is > just adding a path, a restart isn't needed. If a user is replacing 1 jar > file with a different jar file, then a restart is needed. > > In light of that, I still think it is nice to have the ability to define a > set of classpaths for a given testplan. this does save users time and avoid > copying lots of extra jar files to jmeter/lib/ directory. > > > if there's no objects, I'll clean up the code and check it in. > > peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
