You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Peter Lin <wo...@gmail.com> on 2005/09/21 19:32:28 UTC
Classpath feature status
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
Re: Classpath feature status
Posted by sebb <se...@gmail.com>.
Thanks!
Moving the setup code to TestStarted() has solved 2) as well - the
path will now be updated at most once per test run, which is fine.
S.
On 23/09/05, Peter Lin <wo...@gmail.com> wrote:
>
> I fixed #2, so it works in nongui mode. I can take a look at #1 tomorrow.
> going to rest now.
>
> peter
>
>
>
> On 9/23/05, sebb <se...@gmail.com> 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 <se...@gmail.com> 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 <ms...@apache.org> 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:
> jmeter-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> jmeter-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> jmeter-dev-help@jakarta.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Classpath feature status
Posted by Peter Lin <wo...@gmail.com>.
I fixed #2, so it works in nongui mode. I can take a look at #1 tomorrow.
going to rest now.
peter
On 9/23/05, sebb <se...@gmail.com> 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 <se...@gmail.com> 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 <ms...@apache.org> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
Re: Classpath feature status
Posted by Peter Lin <wo...@gmail.com>.
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 <se...@gmail.com> 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 <se...@gmail.com> 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 <ms...@apache.org> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
Re: Classpath feature status
Posted by sebb <se...@gmail.com>.
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 <se...@gmail.com> 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 <ms...@apache.org> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Classpath feature status
Posted by sebb <se...@gmail.com>.
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 <ms...@apache.org> 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: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
Re: Classpath feature status
Posted by Michael Stover <ms...@apache.org>.
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: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org