[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Extending test harness to include "fork" for run command

> I propose to
> extend the harness to support Ant-like "fork" and "jvmargs" attributes 
> for
> the "run" command to allow tests to be run in a separate JVM.

Forking was supported globally with system properties. vmargs are
now also supported globally, as well as with fork and vmargs attributes 
on the run entity for a specific test.

(1) system properties interface supported
    Use -Djavarun.fork=true, -Djavarun.vmargs=...)
(2) java attributes for vmargs and fork
    Specify in run:
       <run fork="true" vmargs="..." ../>
But I don't think this will work because the vmargs have to
specify the classpath and aspectpath.  Both are relative to
the harness temporary sandbox (and thus calculated at
runtime), and there's no basis now for calculating the 

So the easiest upgrade would be to support an aspectpath="..." 
attribute in <run>.  JavaRun would enter "fork-ltw" mode as a result,
searching the sandbox input and output directories
for jar/zip files with that name and construct the fork accordingly,
inferring classpath as usual.  (The jar/zip files could be checked
in or created by an earlier ajc compile to outjar.)  This is feasible 
but involves a lot of assumptions/logic in JavaRun.  I'm not 
certain it's general enough for testing LTW long-term.  Is it?
(legions of test developers?)


For those who want to dig in, here are some issues with
specifying load-time weaving tests:

- if the java vm is being forked with a new bootclasspath,
  then the compiler should be run with that bootclasspath.
  But normally the information doesn't flow backwards from
  a subsequent run step to a prior compile step.  Prior to 
  this, the fork/bootclasspath setup was global, in support
  of testing on a Java 1.1 VM.  To make test-specific
  forks means dropping this global reference, so we would
  have to skip tests that specify forking when testing 
  against 1.1 VM's. hmm.
- To fork the java vm with the load-time weaver,

  - the classpath for the tools needs to be on the VM classpath
    (including all projects, etc. when running from Eclipse)
    This is doable (System.getProperty("java.class.path")).

  - the test needs to communicate failure via System.err
    (again, doable now - see <run errStreamIsError="true" .../>)
    or by throwing an exception.

  - the run classpath has to be calculated and put in the 
    system properties.  It is calculated relative to the
    temporary sandbox location.  Right now we assume that
    the run classpath is just the bootclasspath and the
    output directory, so that's a limitation.
  - the aspectpath has to be calculated.  This is like the
    classpath in being sandbox-relative, but unlike anything
    else, it is potentially based on jar files that are
    produced during an earlier compile run.  So we need a 
    little language for telling JavaRun what to look for
    (the search has to be deferred until after the 
    compiler run has completed).  For now we can just specify
    the jar file name and do a sandbox-relative search.

Some alternatives:

- If we instead had a main-class launcher for LTW, we could
just run that in-process, so that the woven classes were 
loaded and run in a child class loader.  Much faster, and
it would work in any VM supporting those classes.

- A nice alternative would be to run any test we could using binary 
or load-time weaving rather than a compiler.  That would require 
a clear and test-visible distinction between unpluggable aspects,
unpluggable pure-java files, and other code.  Consider the
<compile> attributes:

  files: java or aspectj code compiled together
  javac: java code compilable without aspects
  uaspects: aspectj code compilable without files or javac

Then the harness could run the "same" test in different modes 
(ignoring incremental): 
(a) compile/weave both files and aspects, run;
(b) compile files, compile aspects, weave both, run;
(c) compile files, compile aspects, ltw-run;
(d) above, using output directories or output jars
(..) other variations?

(But this breaks the harness mapping of steps to components.)

Do test developers have a preference?

I'm on the fence (a) whether <ltw> shouldn't be a separate component
(like <run> == JavaRun) or whether to upgrade JavaRun, and 
(b) which of three approaches will work in the long run:

- add minimal attributes (aspectpath) to <run>/JavaRun,
  and live with the default weaving logic it implements.
- add attributes and context to pass around the binaries,
  putting some logic in the existing components but leaving
  it mainly in the test specification (<run> or <ltw>)

- specify only unpluggable aspects, and let the harness generate
  variants of compile/weave/run

- support scripting (beanshell?) to get the harness out of 
  the business of specifying scenarios

The first option is most doable, so we'll default to that.

> ------------Original Message------------
> From: Matthew Webster <matthew_webster@xxxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Thu, Sep-30-2004 12:00 PM
> Subject: [aspectj-dev] Extending test harness to include "fork" for run command
> There are a couple of new situations where there is a need to run a 
> test in
> a new JVM. To fully test load-time weaving we need to use
> "-Djava.system.class.loader" and to test AspectJ in a SecurityManager
> environment we need "-Djava.security.manager" (Bug 74238). I propose to
> extend the harness to support Ant-like "fork" and "jvmargs" attributes 
> for
> the "run" command to allow tests to be run in a separate JVM.
> What do people think?
> Matthew Webster
> AOSD Project
> Java Technology Centre, MP146
> IBM Hursley Park, Winchester,  SO21 2JN, England
> Telephone: +44 196 2816139 (external) 246139 (internal)
> Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
> http://w3.hursley.ibm.com/~websterm/
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev