OK by me. It would be useful to add a comment to jmeter.properties that it is optional, and does not replace the existing classpath; also to document whether the additional entries are appended or pre-pended to the path...
S On 19/09/05, Peter Lin <[EMAIL PROTECTED]> wrote: > I plan to add support for adding classpath to jmeter.properties today. right > now I'm thinking > > user.classpath > > as the entry name. any suggestions or alternate names for the entry? > > peter > > > On 9/16/05, sebb <[EMAIL PROTECTED]> wrote: > > > > OK. > > > > [The actual classpath changes need to be done outside the GUI, or > > non-GUI runs won't work.] > > > > I think it would be useful to also have the ability to define the > > extra classes via a property. > > This could be added to the standard classpath, as it would not need to > > be removed. > > > > S. > > On 16/09/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > > mike and I were chatting yesterday and the testplangui seems like the > > best > > > place to put the feature. this way, users can browse and select the > > desired > > > jar file. > > > > > > I was thinking about how setting/resetting the classpath should work. > > I'll > > > need to do some basic research and see if I should create a new instance > > of > > > the classloader for the jars. since URLClassLoader doesn't have a > > removeURL > > > method. > > > > > > http://java.sun.com/j2se/1.4.2/docs/api/java/net/URLClassLoader.html > > > > > > I could take the servlet container approach, which would mean. > > > > > > 1. create a new classloader to load the jar files > > > 2. if the user resets the classpaths, kill the Classloader instance and > > > create a new one > > > > > > > > > peter > > > > > > On 9/16/05, sebb <[EMAIL PROTECTED]> wrote: > > > > > > > > Point taken. > > > > > > > > Not sure it would make sense to have more than one classpath in a > > > > TestPlan, so perhaps the best place for it would be to add it to the > > > > TestPlan element. > > > > > > > > However ... > > > > > > > > If the extra class-path entries are only needed whilst running a test, > > > > then it should be fairly straightforward to update the CP, though one > > > > would need to make sure the CP did not grow for each test run or loop > > > > - and ideally the CP would be reset if the extra path(s) were removed > > > > or changed later. > > > > > > > > If the CP entries are needed at "design" or startup time, then it > > > > starts to get rather tricky to ensure that the CP is updated before it > > > > is needed. > > > > > > > > S. > > > > On 15/09/05, Serguei Belikov <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > > > > > I think it makes a perfect sense to keep a class paths with a test > > plan. > > > > > In this case one will be able to open a new test plan and the class > > > > > paths will be modified according to plan content. If class paths are > > set > > > > > as a properties, one needs to restart JMeter. > > > > > > > > > > sebb wrote: > > > > > > > > > > >Not sure it's necessary to have a GUI to do this. > > > > > > > > > > > >The additional classpaths are probably known before starting > > JMeter, > > > > > >so would it not be simpler to use a property to define the extra > > > > > >classpaths? > > > > > > > > > > > >S. > > > > > >On 15/09/05, Peter Lin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > >>I'm planning on adding another feature to the 2.1 branch and > > provide a > > > > way > > > > > >>for users to add classpaths to JMeter in the GUI. > > > > > >> > > > > > >>I was thinking of something like User Defined Classpath. Users can > > > > then > > > > > >>select the jar files they want and the config element will add > > them to > > > > the > > > > > >>classloader. Any thoughts, suggestions, ideas? > > > > > >> > > > > > >> > > > > > >> > > > > > >>peter > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > >For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > Serguei Belikov > > > > > Sr. Developer > > > > > Tucows Inc. > > > > > [EMAIL PROTECTED] > > > > > (416) 535-0123 Ext. 1297 > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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]
