Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] advanced(?) percflow uses

:: Now the pointcut is going to match two points when you call 
:: updateAll. Is that what you want? Maybe not.

well, the more powerful or general tool you create, the wiser you must
use it. in my case it works with an additional !within() condition. but
you are right that it's brittle for sloppy pointcuts and even minor code
refactorings.

:: So by example I mean something about as concrete as this, 
:: that is enough to be convinced that the enclosingExecution 
:: pointcut would really work in concrete practice.

<skippable try to describe what i want>

hmm... i have no idea how i could put it in a more concrete example, so
i write down what i would like to achive, and that it's useful, and
there's no current way (i know of) to do that in aspectj.

i would like to collect information (result of computation) from an
arbitrary point in an entire subsystem, and have it optionally.

in other words: i would like to have an optional aspect instance per
cflow to all public methods of a subsystem to provide a transparent
communication between any point of the subsystem and the caller. in my
case the communication would be a list of messages, that can be added to
from arbitrary depth in the control flow under the public methods of a
given subsystem.

currently i can only achive a per cflow aspect instance that lives only
until the call returns. but the information is only useful after the
call returned, so i need to catch the call site in the per cflow
expression. i can either do that by an enclosingExecution() (clowabove?)
or by listing all the places from where the subsystem is called. the
second is error-prone.

</skippable try to describe what i want>

i just have another idea that works currently: create a percflow()
aspect like this:

aspect WaringCollector percflow(call(* Subsystem.*(..)))
{
	Object getResult();
	List getWarnings();
}

WarningCollector Subsystem.someMethod()
{
	...
	
	WarningCollector.aspectOf().setResult(returnValue);

	return WarningCollector.aspectOf();
}


but this way i lose the typing of the return type, and what if i want to
have two such aspects simultaneously?

so what i can argue for is not a generic enclosingExecution() (altough i
prefer few but more owerful tools to many special ones) but some
percflow() semantics where the aspect instance is available one level
above the cflow expression. or maybe controllable by the user when the
percflow aspect instance is released.

and the why is:

- this way i can list a well defined set of methods instead of all the
places from where these methods are called
- i can avoid interdependency between the two systems (if i list the
call sites in S2 instead of the public methods of S1, then i have to
compile S1 and S2 in one step. otherwise only S2 would depend on S1
(with aspectjar))

regards,

- 101



Back to the top