[
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
aspectpath.
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?)
Wes
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
>
