[aspectj-users] One down but still percflow bug

["Bozic, Chris" <cbozic@xxxxxxxxx>]

Thanks for fixing that interface bug so quickly!  Using the development compiler, I can now jar up all of my common project without using the -XnoWeave option and use that jar in a dependant project's aspectPath without getting compiler errors.

Now that I'm able to build my dependant project normally, I still have the percflow bug to report.  Basically, when I compile all the aspect source with the test case source, I get a new instance of my percflow aspect for each cflow (which is the the behavior I expect).  When I jar up my aspects and compile my testcases with the jar in only the aspectPath, I only get one instance of the percflow aspect reguardless of cflow.

I used a bytecode decompiler to see how the AJ compiler generated the code differently.  Here is the all-source decompile of the method my pointcut picks out to define the cflow:

    public boolean myPerCflowEntryPoint(TestClass0 arg0, TestClass1 arg1)
        throws Exception
    {
        byte byte0;
        byte0 = 0;
        if(!TestTransactionContext.ajc$cflowStack$0.isValid())
        {
            byte0 = 1;
            TestTransactionContext.ajc$perCflowPush();
        }
        Object aobj6[] = new Object[0];
        TestTransactionContext.ajc$cflowStack$4.push(aobj6);
        ...
        ...
        ...
    }

This above code does the perCflowPush().  Next is the aspects-from-jar version.  Here is the same testcase method in decompiled source version:

    public boolean myPerCflowEntryPoint(TestClass0 arg0, TestClass1 arg1)
        throws Exception
    {
        Object aobj5[] = new Object[0];
        TestTransactionContext.ajc$cflowStack$2.push(aobj5);
        ...
        ...
        ...
    }

Notice the absence of the perCflowPush().

I hope this information helps.
Chris Bozic

<<winmail.dat>>