|
From: Philip A. <ph...@ma...> - 2013-09-22 11:19:16
|
Ed, Sorry for the delay. I like the strategy of also searching grinder.jvm.classpath, but I'm concerned that you've changed its interpretation. Its important that grinder.jvm.classpath is evaluated relative to the working directory. Can you do it in twoo steps - try to find the agent in the rebased system classpath, and fall back to searching the (non-rebased) grinder.jvm.classpath otherwise? - Phil On 03/09/13 12:52, edb...@gm... wrote: > Phil, > > I quickly came to the same conclusion about introspecting the jar's > manifest, and I very much agree with #1. > > I made some proof-of-concept changes to the WorkerProcessCommandLine > <http://sourceforge.net/p/grinder/code/ci/release_3.11_final/tree/grinder-core/src/main/java/net/grinder/engine/agent/WorkerProcessCommandLine.java> for > debug-logging purposes within my own project, and I had some success > by simply iterating over both system.classpath and > grinder.jvm.classpath when searching for the jar. I just hadn't yet > forked The Grinder to make you a clean patch yet. > > Interesting bits: > > in the constructor: > final List<File> systemClasspath = getClasspath(workingDirectory, > systemProperties.getProperty("java.class.path", ""), > properties.getProperty("grinder.jvm.classpath", "")); > > getClasspath: > > public static List<File> getClasspath(final Directory workingDirectory, final String... propertyLists) { > final List<File> systemClasspath = new ArrayList<File>(); > for (String classpathFragment : propertyLists) { > log.debug("Looking at directory: {}", classpathFragment); > systemClasspath.addAll(workingDirectory.rebasePath(classpathFragment)); > } > > ClassLoader cl = WorkerProcessCommandLine.class.getClassLoader(); > > for(URL url: ((URLClassLoader)cl).getURLs()){ > log.debug("Looking at URL {}. File portion is {}", url, url.getFile()); > File e = new File(url.getFile()); > systemClasspath.add(e); > } > > return systemClasspath; > } > > Thoughts? > > > -Ed Brannin > edb...@gm... <mailto:edb...@gm...> > cell: 585-261-0279 > > > On Mon, Sep 2, 2013 at 1:52 PM, Philip Aston <ph...@ma... > <mailto:ph...@ma...>> wrote: > > I think interpreting the manifest directly is getting a little too > complex. AFAIK, you can only get the manifest from a jar, and to > find the jar, you probably have to walk the class path. I already > assume a URLClassLoader, so this is possible, but I'd like to > remove that assumption if possible. > > Two alternative ideas to consider (either would involve changes to > The Grinder) > > 1. Add a way to tell the agent process to find the agent jar in > an alternative, specific location (Note the two meanings of > agent in the last sentence). This could be a new property in > grinder.properties (which can be set as a system property in > the usual way). If not set, the existing algorithm will be > used. If no agent jar is found, the agent process should fail > with an error, rather than the current behaviour of warning > and continuing. > 2. Package the jar within the agent jar file. On start up, the > agent jar file unpacks it to a temporary location and passes > the path on the worker command line. > > I like #1 much more than #2. > > Thoughts? > > - Phil > > > On 28/08/13 16:37, edb...@gm... > <mailto:edb...@gm...> wrote: >> Phil, >> >> Than you for your reply! I've figured out what's going on here: >> >> I'm running my code with "java >> -Dgrinder.propfile=classes/grinder.properties *-jar >> api-grinder-public-1.0-SNAPSHOT.jar* agent", and it's loading the >> Grinder jars (among others) from the jar's manifest (below). >> >> WorkerProcessCommandLine is looking for jars with >> systemProperties.getProperty("java.class.path", "") but that only >> returns the jar I'm building. >> >> It's also scanning the working directory, but that doesn't help >> because all my third-party jars are currently getting built into >> a 'lib' folder. Worst-case, I can tell Maven to put all my >> dependencies in the same directory as the main jar. >> >> First, I'm going to check if there's an easy way for >> WorkerProcessCommandLine to find the main jar's Class-Path >> Manifest value and include that in its search. >> >> Thanks again, >> -Ed >> >> Manifest: >> >> [C:\dev\misc\grinder-from-scratch]fab manifest >> [localhost] local: unzip -p >> api-grinder-public-1.0-SNAPSHOT.jar META-INF/MANIFEST.MF >> set comspec=C:\PROGRA~1\JPSoft\TCCLE1~1\TCC.EXE >> Manifest-Version: 1.0 >> Archiver-Version: Plexus Archiver >> Created-By: Apache Maven >> Built-By: u0100661 >> Build-Jdk: 1.7.0 >> Main-Class: com.edbrannin.grinder.App >> Class-Path: *lib/grinder-3.11.jar* >> *lib/grinder-dcr-agent-3.11.jar* lib/gr >> inder-http-3.11.jar lib/grinder-core-3.11.jar >> lib/asm-3.2.jar lib/pic >> ocontainer-2.13.6.jar lib/jython-standalone-2.5.3.jar >> lib/slf4j-api-1 >> .6.4.jar lib/logback-classic-1.0.0.jar >> lib/logback-core-1.0.0.jar lib >> /grinder-httpclient-3.11.jar lib/grinder-xmlbeans-3.11.jar >> lib/jsr173 >> -1.0.jar lib/xmlbeans-2.5.0.jar lib/stax-api-1.0.1.jar >> lib/grinder-co >> nsole-service-3.11.jar lib/clojure-1.4.0.jar >> lib/tools.logging-0.2.3. >> jar lib/ring-core-1.1.0.jar lib/commons-codec-1.6.jar >> lib/commons-io- >> 2.1.jar lib/commons-fileupload-1.2.1.jar >> lib/servlet-api-2.5.jar lib/ >> clj-time-0.3.7.jar lib/joda-time-2.0.jar >> lib/ring-jetty-adapter-1.1.0 >> .jar lib/ring-servlet-1.1.0.jar >> lib/jetty-server-7.6.1.v20120215.jar >> lib/javax.servlet-2.5.0.v201103041518.jar >> lib/jetty-continuation-7.6. >> 1.v20120215.jar lib/jetty-http-7.6.1.v20120215.jar >> lib/jetty-io-7.6.1 >> .v20120215.jar lib/jetty-util-7.6.1.v20120215.jar >> lib/ring-middleware >> -format-0.2.0.jar lib/core.memoize-0.5.1.jar >> lib/core.cache-0.5.0.jar >> lib/cheshire-4.0.0.jar lib/jackson-core-2.0.0.jar >> lib/jackson-datafo >> rmat-smile-2.0.0.jar lib/clj-yaml-0.3.1.jar >> lib/snakeyaml-1.5.jar lib >> /compojure-1.0.4.jar lib/core.incubator-0.1.0.jar >> lib/tools.macro-0.1 >> .0.jar lib/clout-1.0.1.jar lib/clj-stacktrace-0.2.4.jar >> lib/grinder-s >> wing-console-3.11.jar lib/jedit-syntax-2.2.2.jar >> >> >> >> >> >> >> >> -Ed Brannin >> edb...@gm... <mailto:edb...@gm...> >> cell: 585-261-0279 <tel:585-261-0279> >> >> >> On Wed, Aug 28, 2013 at 4:56 AM, Philip Aston <ph...@ma... >> <mailto:ph...@ma...>> wrote: >> >> Looks like your custom build/launch is doing one of: >> - not correctly creating the DCR agent jar, >> - putting it in a location where the grinder agent can find it >> - giving it a different name, so the grinder agent can't find it >> >> I can tell this from the command line that the grinder agent >> writes out. You should see the javaagent parameter, e.g.: >> >> 2013-08-28 09:35:27,716 INFO agent: Worker process command >> line: java >> '*-javaagent:/home/philipa/src/grinder-git/grinder-dcr-agent/target/grinder-dcr-agent-3.12-SNAPSHOT.jar'* >> -classpath ... >> >> whereas you have >> >> 2013-08-27 11:13:00,384 INFO agent: Worker process command line: java -classpath ... >> >> See >> http://sourceforge.net/p/grinder/code/ci/release_3.11_final/tree/grinder-core/src/main/java/net/grinder/engine/agent/WorkerProcessCommandLine.java >> for the algorithm the grinder agent uses. It looks for a >> files that are peers of other jars in the classpath and start >> with "grinder-dcr-agent-" followed by a version number, >> following by an optional " -SNAPSHOT" qualifier, followed by >> ".jar". >> >> So it *should* match "lib\grinder-dcr-agent-3.11.jar", which >> I see in the classpath output by the worker. Can this be >> found from the classpath used to start the agent? Or have you >> added it to grinder.jvm.classpath, and it doesn't actually exist? >> >> Does it work when you "run standalone"? >> >> You may be trying to be trying to hard to add all of the >> grinder dependencies to the classpath. Usually, you only need >> the classpath to contain the grinder.jar. The other grinder >> jar files are referenced via a manifest classpath. >> >> - Phil >> >> >> On 27/08/13 16:23, edb...@gm... >> <mailto:edb...@gm...> wrote: >>> I'm trying to get started with The Grinder, and I want to >>> try using Maven to manage my dependencies. >>> >>> Sadly, every attempt I've made so far has The Grinder >>> failing to load DCR, even though my classpath appears to be >>> correct. >>> >>> I've posted my code >>> at https://bitbucket.org/edbrannin/growl-with-maven-help and >>> dumped my console output & logs into the bottom of the >>> README on that page. >>> >>> So, what am I doing wrong here? >>> >>> Thanks, >>> -Ed Brannin >>> edb...@gm... <mailto:edb...@gm...> >>> >>> >> >> > > |
