Re: [aspectj-users] Possible percflow compiler bug

[Wes Isberg <wes@xxxxxxxxxxxxxx>]

-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