Re: [clif] deployment of Webtest class as scenario

[Bruno Dillenseger <bruno.dillenseger@xxxxxxxxxxxxxxxxxxxx>]

olivier gusching wrote:

> The purpose of this mail is the deployment of Webtest class as a 
> scenario.
>
> I have compiled the latest CVS release of clif and now use the 
> up-to-date clif jars.
> Now I'd like to customize the Webtest class, provided into the 
> examples, and deploy it. 

> I've compiled it and try to deploy the Webtest.class file, which I 
> have not included in a jar file. My problem is that, on deployment, 
> when I don't specify parameters, I get a message from 
> org.objectweb.clif.scenario.util.multithread.MTScenario (saying that 
> the class takes two arguments), not from the Webtest class. This is 
> strange : as it is the superClass of Webtest, I should rather get 
> messages from Webtest than MTScenario. 

Since Webtest class have no constructor, MTScenario's constructor is 
called. This constructor requires AT LEAST 2 arguments (number of 
threads and duration in seconds). Once this constructor has "consumed" 
these 2 arguments, it keeps the remaining string to provide an argument 
when creating a new MTScenarioSession instance, when calling the 
newSession() method. In the case of Webtest example, this remaining 
string should contain two arguments (think time in seconds and file 
containing the list of URLs). As a result, a Webtest scenario requires 4 
arguments.

> When I specify parameters, the console catches a ClassNotFound 
> exception on deployment. 

Classloading features are a little bit tricky, but I try to explain:
The CLIF servers are basically just Fractal empty composites, (almost) 
only requiring a Julia/FractalRMI runtime. When instantiating a CLIF 
component (such as a probe or a scenario), every classes are downloaded 
from the console (which embeds a pseudo-web server listening on port 
1357, dedicated to class loading requests) via HTTP. The RMIClassLoader 
handles this, accordingly to the value of system property 
java.server.codebase. This value should contain a HTTP URL targetting 
the base directory of the example's classes (relative to the directory 
from where the console has been launched, i.e. the root of CLIF's 
unzipped binary distribution, or the output/dist directory generated by 
CLIF's compilation), with a mandatory trailing slash "/".

If you also need classes and resources from a jar file, this jar file 
should be copied to the lib/ext/ directory (relative to output/dist 
directory, or to the root of the binary distribution).

If you use build.xml file in examples, everything is automatically 
handled, except that you have to modify the etc/clif.props to replace 
every occurrence of text "SET_CONSOLE_HOST" by the hostname where the 
console is running.

> Perhaps I have not understood the proper location where this class has 
> to be put, perhaps there's something else wrong.
>
> Any advices ?

1- ensure that the scenario class is in directory examples/classes/, and 
associated jars in lib/ext/ directory
2- change every occurrence of text "SET_CONSOLE_HOST" in file clif.props
3- due to the functioning of the RMI Class Loader, the scenario class 
will be downloaded only once. If you change a scenario class that you 
had already deployed, then the CLIF servers have to be killed and 
restarted. This is not satisfactory, but I'll work on it (someday this 
year, I hope - I know the solution, but it requires some time to do 
something nicely integrated to Fractal, and to implement). Another 
(dirty) workaround is to rename your scenario class at each new version, 
if you want to go on wihout killing and restarting the system.

Thanks for you interest in CLIF,
-- Bruno.