[
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
|
<run> now supports aspectpath=..., which forks with LTW.
For setup, see tests/readme-writing-compiler-tests.html.
Some issues with recent weaver updates:
- ajcore... files are being generated in the working directory
of the harness because AjdtCommand assumes the setup of the
main AspectJ class (not used by the harness). I'd prefer an
optional cast to IMessageHolder in AjdtCommand so it could
enforce its otherwise scattered/implicit expectations, or...?
- weaveinfo messages are generated by default to System.err
during LTW, which causes the forked process to appear to
be failing. I couldn't find an easy way to disable these,
which should probably be silent by default, or at least
controllable with XLint. (Stuff more stuff into properties?)
Cheers,
Wes
P.S. - CompilerRun bug: it sets up bootclasspath
both in response to a -source 1.{234} and in response
to a global -Djavarun.bootclasspath=..., but not in
response to a run-local bootclasspath. Needs to be
consistent.
> ------------Original Message------------
> From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Wed, Oct-6-2004 2:05 AM
> Subject: 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
> >
>
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
