Right, thanks! That is exactly because my file is not found, it is not searched in the user.classpath as soon as I use the system classloader.
The next problem is that the system class path cannot be overriden, isn't it? First it is not part of the jmeter.bat command and secondly, the -jar option ignores the classpath (either -cp or CLASSPATH env variable). To make it work quickly, I've used an ugly classpath hack (http://forum.java.sun.com/thread.jspa?threadID=300557&tstart=240). Fabrice -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: lundi 29 octobre 2007 18:59 To: JMeter Users List Subject: Re: Calling getSystemResourceAsStream in Test Element That uses the system class loader. The user.classpath contents are added to the context classloader, which may not be the same. On 29/10/2007, DELHOSTE Fabrice <[EMAIL PROTECTED]> wrote: > > Actually, in my code, I do: > > ClassLoader.getSystemResourceAsStream("file.properties"); > > The file.properties is in a directory "<dir>/conf". > So I added "<dir>/conf" to the classpath. > This is to avoid absolute path for global configuration file in file > system, not jars. > That works fine in my app. > > It *seems* (I have to confirm or not by unit test) not to work by > setting user.classpath to "<dir>/conf" in jmeter.properties. > But what I don't understand is that, in my sampler code, when I check > the java.class.path property just before loading the file, it is ok. > > Fabrice > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: lundi 29 octobre 2007 18:30 > To: JMeter Users List > Subject: Re: Calling getSystemResourceAsStream in Test Element > > How are you referencing the resource file? > > If it is a/b/c/d/file.properties, then I think the classpath needs to > contain the parent of the directory a, not the directory a/b/c/d itself. > > Whereas in a jar file, the jar needs to be in the classpath, and the > file within the jar needs to be a/b/c/d/file.properties. > > Either way, Java will add a/b/c/d to the classpath. > > On 29/10/2007, DELHOSTE Fabrice <[EMAIL PROTECTED]> wrote: > > > > I've dumped it and even if it is very long, the latest directory is > > mine. I tried both relative and absolute path. > > > > Then, just to test, I've tried to include my property file in a JAR > > file and adding that JAR file to classpath (in jmeter.properties) > > instead of adding the directory with the resource file in it and it > works... > > > > I'm thinking to write a sample out of my context to be sure but a > > bit lazy today... :-) > > > > Fabrice > > > > -----Original Message----- > > From: sebb [mailto:[EMAIL PROTECTED] > > Sent: lundi 29 octobre 2007 16:33 > > To: JMeter Users List > > Subject: Re: Calling getSystemResourceAsStream in Test Element > > > > On 29/10/2007, DELHOSTE Fabrice <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > I'm having problem to load a resource in a test element, > > > overriding classpath. > > > > > > Actually, I call ClassLoader.getSystemResourceAsStream() in some > > > code external to JMeter, loading a property file available on the > > > filesystem (not in JAR). > > > When calling that code, my custom sampler is unable to find the > > > resource file whereas it works outside JMeter. > > > I don't want to change that code, which works normally outside > JMeter. > > > > > > Obviously, I have added the directories containing that resource > > > to user.classpath in jmeter.properties. > > > I've checked all common classloading stuff but cannot make it work. > > > > > > Any idea? Am I missing something? > > > > I suggest you dump out the contents of the classpath in the code you > > are using to interface with your external API. > > > > Indeed what happens if you call > > ClassLoader.getSystemResourceAsStream() in the interface code? > > > > > Fabrice > > > > > > > > > > -------------------------------------------------------------------- > > - 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] > > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- 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]
