[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-users] Possible percflow compiler bug
|
A test case would of course be great!
But I'm still hoping that the current fixes would work for you,
so perhaps you can wait until the release candidate before
writing tests or refactoring your code. I'm also trying it.
btw, I'm still not exactly sure what you're doing, and why the
interfaces aren't behaving as expected. Note that the methods
declared on the interfaces in the aspect must explicitly be declared
public for them to be visible to types. What I recommend:
- compile library as usual: ajc -outjar library.jar ...
- compile others as usual: javac ...; jar cf others.jar ...
- weave: ajc -outjar system.jar
-injars others.jar
-aspectpath library.jar
-classpath aspectjrt.jar
- run: java -classpath "aspectjrt.jar;system.jar;library.jar" ...
Wes
Bozic, Chris wrote:
Wes,
Thanks for responding so quickly. I've tried the options you gave but without success. I think as things are now, the stateless aspect solution you suggested might be the best thing for me to look into now. However, since we're talking about a potential bug, I'll try to be more helpful by giving a little more detail.
I have a project of common components that I would like to jar up and include in other projects. This common project contains mostly interfaces with aspect introduced implementations (for mixins) along with a few other handy tools like the TransactionContext I mentioned earlier. The interfaces declare methods that throw exceptions. If I compile without the -XnoWeave option, the project compiles and the jar builds fine. But, when I use that jar in another project in the -aspectPath option, I get compiler errors saying the interface methods throwing exceptions in the original source are no longer throwing them in the jar.
[ajc]C:\apps\eclipse30M2\workspace\commonSAIC\src\java\com\saic\uri\persistance\UriPersistableAspect.java
:55 overriden method doesn't throw com.saic.persistance.PersistanceException
If I compile and create the jar with the -XnoWeave option, I can use it in dependant projects by compiling them with that jar in the -aspectPath and -inJar options. Everything passes tests except for the TransactionContext where it tries to get a new instance of the aspect percflow.
To summarize, I basically have two mutually exclusive problems. One is that my introduction seems to be stepping on itself in jar form and the other is the percflow giving me only one instance of an aspect. Unless I'm missing something, I can't jar up my code already woven becuase the exceptions on the interface methods vanish and the compiler seems to want to re-weave the jar even when it's not used in the -inJar option. If there's a way I can do that, then my problem might be solved. Otherwise, I might need to submit a bug report for the single instance of a percflow aspect. Maybe it's not really an official bug at all because it happens when I use experimental compiler options.
Please let me know if some code examples are needed or if you would like me to write test cases for anything.
Chris Bozic
-----Original Message-----
From: Wes Isberg [mailto:wes@xxxxxxxxxxxxxx]
Sent: Tue 8/5/2003 1:54 PM
To: aspectj-users@xxxxxxxxxxx
Cc:
Subject: Re: [aspectj-users] Possible percflow compiler bug
-XnoWeave is an experimental (read: unsupported) option.
To use binary aspects, compile them without the -Xnoweave option
and then weave them with your classes using -aspectpath.
Let us know if that works. If it doesn't, there was a cflow(..)
bug that has been fixed in the tree. We're soon to post a link
on aspectj-dev@xxxxxxxxxxx to the 1.1.1 release candidate which
will include that fix. Try the release candidate. If that
doesn't work, then we'd want to write up a bug and work up a
reproducible test case so we can investigate if possible
before the release of 1.1.1. Finally, as a workaround
you can be thread-safe if your aspect is stateless (or
has no state changes). Sometimes you can use around
advice and local variables to manage any required
thread-specific state, or declare fields on targets
that themselves are thread-safe, to avoid having a
stateful aspect.
Thanks for bringing this up.
Wes
https://bugs.eclipse.org/bugs/show_bug.cgi?id=40876
Bozic, Chris wrote:
All,
My team has a TransactionContext that either commits or rolls back a set of DB interactions based on whether an exception has occured during one of the interactions. In order to be thread safe, we have declared this aspect to be a percflow aspect ( "percflow( topOfFlow() )" ). Everything works fine if we compile the original TransactionContext source with our test cases. However when we jar our source (compiled with the -noweave option) and then bytecode weave it in to our testcase source files, we get the same instance of TransactionContext for every topOfFlow().
We were wondering if anyone could suggest a way to fix this or if we have found a bug that we should submit.
Thanks,
Chris Bozic
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users
