[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] Compiling and not weaving
|
Hi Andy,
thanks for your explanation, and sorry for taking some time to test it
out before answering.
I tried disabling pipelining as described in bug 146781, that is using
-Xset:pipelineCompilation=false, but unfortunately I get this error
while compiling with -XterminateAfterCompilation :
java.lang.NullPointerException
at org.aspectj.weaver.ReferenceType.isAspect(ReferenceType.java:160)
at
org.aspectj.ajdt.internal.core.builder.AjBuildManager$4.addAspectName(AjBuildManager.java:1108)
at
org.aspectj.ajdt.internal.core.builder.AjBuildManager$4.acceptResult(AjBuildManager.java:1047)
at
org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.acceptResult(AjCompilerAdapter.java:253)
at
org.aspectj.ajdt.internal.compiler.AjCompilerAdapter.afterProcessing(AjCompilerAdapter.java:218)
at
org.aspectj.ajdt.internal.compiler.CompilerAdapter.ajc$after$org_aspectj_ajdt_internal_compiler_CompilerAdapter$5$6b855184(CompilerAdapter.aj:98)
at
org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:641)
at
org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:392)
at
org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:995)
at
org.aspectj.ajdt.internal.core.builder.AjBuildManager.doBuild(AjBuildManager.java:269)
at
org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:184)
at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:112)
at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:60)
at org.aspectj.tools.ajc.Main.run(Main.java:382)
at org.aspectj.tools.ajc.Main.runMain(Main.java:254)
Could it be because the class it is trying to parse is an aspect and,
not being weaved, something is missing? Currently I'm running AspectJ
1.6.1 taken from the maven repository.
I don't fully get the compile step, and why not weaving leads to
unexecutable code, since it should be similar to compiling @AspectJ
classes with a common compiler and then weave them in using LTW. But
before asking you more details I'll go read the code and try to figure
it out by myself.
Regarding my setup, it is not that incredibly complex, and can be
explained quite simply :
- I have a "watch-database" project, that contains some aspects that
provide stuff (ITDs, various intercepting aspects etc..) for database
related operations
- I have a "watch-stream" project, that does the same with streams
- I have some projects that further "specialize" them, like for example
a watch-mysql project that adds specific mysql stuff to the
watch-database main project.
... the watch-mysql package has a dependency on "watch-database" in
maven, it defines aspects that will intercept methods of classes present
in the "watch-database" project, and use methods inferred by ITD by the
"watch-database" project.
All this stuff gets built, and packaged by maven in different jars.
Then, the final user will use maven to say "i want to use the
watch-mysql package and the watch-stream package". Maven will download
jars and place them in both the compile and runtime classpaths.
I cannot place the "watch-database" jar in the inpath of "watch-mysql"
project, otherwise in the watch-mysql.jar file I will have some classes
taken from the "watch-database" package (woven), which will cause
duplicate classes on the classpath on the user.
So, the watch-mysql package will not work correctly, unless LTW (or some
other compile time re-weaving) is in place on the user part, so that
aspects defined in "watch-mysql" can be applied to classes defined in
"watch-database".
Please note that maven is not adding much complexity here, it would have
been the same using any other tool to generate different jars (including
building jars from inside eclipse). As long as weaving happens at
compile time and classes from one project gets woven and placed in the
target directory of another package, duplicate classes will be found
when both jars are used on a target system.
Right now, this is all ok and working properly, cause the end user runs
LTW and everything goes smoothly.
Anyway, aspects defined in the "watch-database" package gets woven
inside classes defined in the "watch-mysql" package. This is because,
while "watch-database" is not in the inpath, it has to be in the
aspectpath, cause many of these packages uses ITDs and not placing them
in the aspectpath would cause compilation errors. Being it on the
aspectpath, ITDs are correctly considered, AND advice gets woven.
If after a couple of days a new version of the "watch-database" package
is deployed, and the developer removed an advice for some reason, the
watch-mysql.jar classes are still woven with that - now missing -
advice. The end user (not always, but it happens) will receive an error,
cause in the bytecode there is a call to a missing method.
If the code of "watch-mysql" was NOT weaved at all, and only LTW was in
place, everything would still work properly (cause of LTW) and each
package could be released independently.
Right now, a change in the "watch-database" package, brings the need to
recompile and redeploy also all other packages which could have been
weaved by advices in that package, to make sure no calls to - now
missing - advice methods are present.
I think that the fact that errors are intermittent is caused by the LTW
re-weaving classes. Sometimes seems like re-weaving does not remove
missing advice. I'll try to setup a test case at least to demonstrate
the problem.
Simone
Andy Clement wrote:
> Oh... let me also add that a better split matching/weaving process is
> under development. From the project plans on
>
> http://www.eclipse.org/projects/project-plan.php?projectid=tools.aspectj
>
> There is a reference to bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=246125
>
> which discusses breaking out the matcher for standalone reuse and thus
> enabling better tools for development of code that will be load-time
> woven later on.
>
> cheers,
> Andy.
>
> 2008/10/3 Andy Clement <andrew.clement@xxxxxxxxx
> <mailto:andrew.clement@xxxxxxxxx>>
>
> Hi Simone,
>
> Have you tried turning off pipeline compilation as well as using
> terminateAfterCompilation? The latter worked perfectly until the
> former was invented - now they may be interfering.
> -XterminateAfterCompilation is not really intended for end users
> and so I have never gotten around to fixing it in relation to
> pipelining.
>
> > - Simulate weaving, both on local classes and on inpath, but
> output only
> > warnings and errors, and don't weave classes
> >
> > Which is somehow similar to what -XterminateAfterCompilation is
> supposed
> > to do, except the simulate weaving part.
>
> -XterminateAfterCompilation is what we used to call noweave and I
> renamed it because I didn't want people incorrectly using it
> because they didn't really know what it did.
> -XterminateAfterCompilation is for me to debug code that came out
> of the compiler before it goes into the weaver, it has no other
> goal than that. And the code that comes out of the compiler in
> some cases (eg. aspects) is incomplete and will not run until the
> weaver has finished it off.
>
> Simulating weaving is currently not easy as the matching and
> weaving are relatively tied together.
>
> The use of ITDs to complete the type system already happens, they
> are 'simulated' during compilation so that we know the type system
> is coherent and then woven in later at weave time.
>
> I'm afraid your setup is a bit too complicated for me to
> understand, any chance of a test case that shows what you want the
> compiler to do?
>
>
> > I think such a feature is needed. Basically, it is something like :
> > - Take this aspectpath
> > - Take these .java and .aj
> > - Take this -inpath
> > - Compile the .java and .aj, taking into consideration the ITD
> present in aspects
> > - DO NOT weave those ITD inside the resulting class files, use
> them only
> > to check possible compilation errors.
> > - DO NOT weave advice in resulting class files
> > - DO NOT weave advice on classes in -inpath
>
> this is what -XterminateAfterCompilation does.
>
> > - Use the -inpath only to properly generate warnings and errors.
>
> -XterminateAfterCompilation will only generate warnings and errors
> for things found at compilation time, nothing for weave time, not
> even for matching.
>
> > Also, it throws a number of exception inside the aj compiler, null
> > pointer mostly, probably while trying to resolve some ITD.
>
> What are these? -XterminateAfterCompilation shouldn't NPE. As i
> say, the code that comes out will not necessarily run but nothing
> should go wrong at compile time - please try it with also turning
> off pipeline compilation.
>
> cheers,
> Andy.
>
> 2008/10/3 Simone Gianni <simoneg@xxxxxxxxxx
> <mailto:simoneg@xxxxxxxxxx>>
>
> Hi all,
> my situation is the following :
> - I have several different projects
> - each one is built with maven
> - as such, it declares dependencies on other projects
> - every project can contain classes, advice and inter type
> declarations
> (both public and private methods and fields)
> - these projects will be then loaded together using LTW in an
> application, OR they will be completely weaved each one on
> each other by
> an external process to produce a "final version".
>
> Up to this, no problem at all. Building it with maven will
> simply work,
> produce all the artifacts and so on, provided that all relevant
> dependencies are present in -aspectpath and nothing is present in
> -inpath (otherwise, multiple copies of the same classes, weaved -
> partially weaved - non weaved at all, will be included in the
> resulting
> jars.
>
> Then, loading it with LTW will "finish" the weaving process,
> making
> aspects defined in some projects also weave classes from
> projects they
> depend to.
>
> I know this explanation is getting complicated, it is not so hard,
> please have the patience to keep reading another minute.
>
> The problem arise when ONLY ONE of the projects is modified
> and then
> deployed. For example, if a project redefined an advice to
> match other
> methods than before, the old jars of other projects will still
> contain
> calls to the old advice, and often fail at runtime. Also, we are
> currently receiving an incredible number of
> Xlint:adviceDidNotMatch
> cause our inpath is empty, to avoid class duplication.
>
> These are major problems, cause we need to rebuild everything
> every time
> a single project releases a new version, or even just to test
> when other
> projects are involved in the test, and have no clue wether or
> not we
> mispelled something in a pointcut, cause
> Xlint:adviceDidNotMatch will
> always be warned,
>
> I tried the -XterminateAfterCompilation switch. It does what it is
> designed for, and produced classes does not contain calls to
> advice, BUT
> it also misses all static intertype declarations, so projects
> depending
> on the presence of a method declared using intertype
> declaration or on a
> certain object implementing a certain interface will fail.
>
> Also, it throws a number of exception inside the aj compiler, null
> pointer mostly, probably while trying to resolve some ITD.
>
> I think such a feature is needed. Basically, it is something
> like :
> - Take this aspectpath
> - Take these .java and .aj
> - Take this -inpath
> - Compile the .java and .aj, taking into consideration the ITD
> present
> in aspects
> - DO NOT weave those ITD inside the resulting class files, use
> them only
> to check possible compilation errors.
> - DO NOT weave advice in resulting class files
> - DO NOT weave advice on classes in -inpath
> - Use the -inpath only to properly generate warnings and errors.
>
> This seems to be somehow similar to :
> - Compile, as always
> - Simulate weaving, both on local classes and on inpath, but
> output only
> warnings and errors, and don't weave classes
>
> Which is somehow similar to what -XterminateAfterCompilation
> is supposed
> to do, except the simulate weaving part.
>
> Is this a reasonable feature to add to AspectJ? More than a
> new feature,
> I think it should be the way -XterminateAfterCompilation works
> anyway.
> This is absolutely needed to have AspectJ and Maven cooperate
> well in a
> project that goes even just a step after the "tracing aspect"
> kind of
> organization.
>
> Is this something I can try to do on my own? I've been reading
> AspectJ
> code lately, but before working on such a (for me big)
> change/fix/feature would like to know if there is any interest
> on it
> and/or any known problems that would prevent it to work correctly.
>
> Simone
>
> --
> Simone Gianni CEO Semeru s.r.l. Apache
> Committer
> MALE human being programming a computer
> http://www.simonegianni.it/
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx <mailto:aspectj-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
MALE human being programming a computer http://www.simonegianni.it/
