I have a flu right now, but I'll try to take a look tonight or tomorrow. I saw repeated update also, but as you saw the classloader handles it correctly. Should we keep track of the URL's and only call loader.add(URL) if the path is new?
a work around for #2 is to move the code for calling NewDriver to testStarted(). I tried that originally, but moved it to the set method. Since the setTestPlanClasspath isn't called in non-gui mode. peter On 9/23/05, sebb <[EMAIL PROTECTED]> wrote: > > I've moved the user.classpath code to JMeter.start(). This seems to work > OK. > > The TestPlan classpath processing has some issues: > 1) the classpath is repeatedly updated during GUI startup, and also as > the user moves around the GUI. Luckily it seems the Sun code ignores > duplicate entries. > 2) the path does not seem to get updated in non-GUI mode. > 3) the classpath is updated too late for some purposes - e.g. I tried > using it to add the beanshell jar, but the BSH sampler did not work. > This is because the BSH Sampler tries to create the BSH manager > before the classpath has been updated. > > I'll try and have a look at these later. (3) may be difficult to fix. > > I think 1 + 2 need to be fixed - or the code should be removed - > before we release 2.1.1 > > S. > On 22/09/05, sebb <[EMAIL PROTECTED]> wrote: > > Seems to me it would be useful to process the user.classpath property > > earlier than at present - it won't change during a run. > > > > Also, the code needs to handle multiple entries in the property value > > - at present it assumes there is only one. > > > > Presumably the separator should be the local system path separator? > > > > Also, I think it would be useful to log the path setting, and perhaps > > warn if any of the path segments were invalid (they should be > > directories or files). Not sure that it is necessary to check if the > > files are of type zip/jar, just that they exist. > > > > Later ... > > > > S. > > On 21/09/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
