[ grinder-Bugs-2315181 ] Classpath of distributed jars

[SourceForge.net]

Bugs item #2315181, was opened at 2008-11-19 16:29
Message generated for change (Settings changed) made by philipa
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=2315181&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: Core engine
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ujik (ujik)
>Assigned to: Philip Aston (philipa)
Summary: Classpath of distributed jars

Initial Comment:
All

Firstly apologies if this is a well worn topic, I am relatively new to The Grinder.

My grinder script depends on several client jars. I need to add these to the classpath of the worker. I can do this by adding these jars to the property grinder.jvm.classpath.

However I would like to be able to distribute these jars along with the script and properties files to the agents. Unfortunately I don’t know what the path of the jars will be after distribution. The dir of the distributed file store is based on the machine name so will be different on different machines. I also don’t want to make assumptions about the agent’s setup, ie launch directory etc. It would therefore be good if these classpath entries could be worked out relative to the property file.

I can’t see how to do this at the moment. If there is a way please let me know if not please read on.

There are many different ways to skin this cat. I have come up with the following.

The directory the worker process is started in could be changed to be the directory containing the property file. This would allow all files looked up in the worker process to be relative to the script.

The path could be processed before invoking the process. Each element could be processed using the same functionality used to make the script relative to the property file. The path at this point could also be converted to the local os standard.

Generic property substitution could be added to the GrinderProperty file with some system properties grinder.home, property.home etc defined before the substitutions are made. The java properties could be used to correct the path for OS using this technique (although this would be ugly).

I havn’t contributed to The Grinder before but am happy to prepare a patch for you to evaluate. Please let me know.

Regards

Ujik


----------------------------------------------------------------------

>Comment By: Philip Aston (philipa)
Date: 2009-09-10 13:57

Message:
Sorry ujik, I need this feature so I'm implementing it myself.

----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2009-01-02 10:32

Message:
I used windows up till about 2 years ago, and linux ever since. The tests
are intended to run on windows. Occasionally you might see some strange
failures on tests that rely on the network, or on those that have timing
sensitivities. Edit build.xml to run <junit/> with haltonfailure="false"
and post details of tests that fail to grinder-development.

----------------------------------------------------------------------

Comment By: ujik (ujik)
Date: 2009-01-02 10:09

Message:
All

Sorry for the delay, I have just got back from my Christmas Holiday. I
will submit the patch shortly.

I am struggling a little with the test suite. I expect that the problems
are caused by the fact I am using Windows. I think the tests were developed
on a Unix system. Has anyone else reported problems with running the tests
on Windows?

Regards

Ujik


----------------------------------------------------------------------

Comment By: Philip Aston (philipa)
Date: 2008-12-19 15:34

Message:
There's a more general problem here as well - there's no API for a script
to read data files from the cache directory. See
http://www.nabble.com/Re%3A-read-test-data-from-file-or-database-p20850708.html
for a work around.

"The directory the worker process is started in could be changed to be the
directory containing the property file."

I rather like this idea. It would also solve the general problem. The
minor drawback I see is that it would break things like relative paths in
grinder.log.directory. But the latter could be changed by the agent to be
an absolute path before the worker was launched.

Please go ahead an prototype a solution based on this. (Read
http://grinder.sourceforge.net/development/contributing.html#How+to+give+back
first).


----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=118598&aid=2315181&group_id=18598

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Grinder-development mailing list
Grinder-development@...
https://lists.sourceforge.net/lists/listinfo/grinder-development