[ grinder-Feature Requests-3517504 ] grinder.jvm.classpath should allow relative paths
SourceForge.net <[email protected]> Fri, 13 Apr 2012 07:54:29 -0700
| Newsgroups | gmane.comp.java.grinder.devel |
|---|---|
| Message-ID | <[email protected]> |
Feature Requests item #3517504, was opened at 2012-04-13 07:54
Message generated for change (Tracker Item Submitted) made by grinder-user
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=368598&aid=3517504&group_id=18598
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: H C (grinder-user)
Assigned to: Nobody/Anonymous (nobody)
Summary: grinder.jvm.classpath should allow relative paths
Initial Comment:
Issue full name: grinder.jvm.classpath should allow relative paths to distribution directory
I am part of a team that is investigating the use of grinder for performance testing/load in a client-server environment were we put load on the server. We want to be able to use designated versions of our software on the grinder agents with each run of the tests. Here is an example: we have released version 1.1 of our software and ran the performance tests with grinder. We then release version 1.2 and we want to run performance tests using version 1.2 of the software.
Here is what we did so far in order to achieve this:
1. Copy our software libraries inside Grinder distribution directory. As such they will be available on the agent.
Here is an example of the distribution directory tree where
agent-distribution-dir
|
-> grinder.properties.
-> helloworld-using-product-libraries.py
-> lib
|
-> library1.jar
-> library2.jar
In this tree:
- The distribution directory is "agent-distribution-dir"
- The directory called "lib" is the one containing the jars of our product (client side). It is a child of agent-distribution-dir
2. Set the grinder.jvm.classpath to point to the lib/*.
3. Set grinder.script to point to a jython script that tries to use a class from library1.jar
4. Start the tests.
After step 4, the agent output will indicate that the required class was not found with "ImportError: no module named ...". Looking at the way the worker is started I noticed that the classpath includes the lib directory but from an incorrect path
2012-04-13 16:04:15,849 INFO agent: Worker process command line: java '-javaagent:../../../lib/grinder-dcr-agent-3.7.1.jar' -classpath '../../project-lib/*:../../../lib/grinder.jar' net.grinder.engine.process.WorkerProcessEntryPoint
The only way to make it work is by specifying an absolute path, which is not desirable considering our jars get delivered within the distribution directory. As such it would be nice to have a way to specify the grinder.jvm.classpath relative to the distribution directory.
If there are any other options to solve the use case of being able to run the tests with a specified version of our software plese let me know!
Best Regards,
Horace
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=368598&aid=3517504&group_id=18598
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2