This question has been vexing me for the last few days. Any
configuration
of a pointcut would have to go through the AspectJ compiler, so what
you're currently doing is about as good as it can get right now.
You could imagine an XML syntax that gets turned into an aspect by some
build step, e.g.
<aspect name="DatabaseTestAspect" extends="
AbstractDatabaseTestAspect">
<pointcut name="applicationCode">within(patterntesting..*)</pointcut>
<pointcut name="allowedCode">within(patterntesting.db..*)</pointcut>
</aspect>
(just for illustration, not a real syntax)
but is that really so much easier to understand than:
aspect DatabaseTestAspect extends AbstractDatabaseTestAspect {
pointcut applicationCode() : within(patterntesting..*);
pointcut allowedCode() : within(patterntesting.db..*);
}
? Especially when you've still got to pass the result through the
compiler
anyway.
I've been talking a lot with the Spring folks at the TSS Symposium,
and I
can see a case for wanting true runtime configuration of pointcut
values
for some infrastructure (auxiliary) aspects - the kind of things that
the
J2EE community is very used to specifying in config files rather than
in
code. One of the exciting things that came out of those discussions is
a
way to use Spring's IoC capabilities to configure aspects (more on that
soon), but this capability doesn't extend to configuring pointcuts
(just
things like the DataSource for a persistence aspect to use etc.). I
wanted
to enable pointcut configuration in the same way, so I've built a
private
prototype today that shows one way it could be done. Here's how it
looks,
and I'd be interested in feedback as to whether others would find this
useful:
Firstly, a new utility class: JoinPointMatcher. JoinPointMatcher is
constructed with a string (in the expected usage this is obtained from
a
config file, but it could be generated in the program itself at runtime
for extreme use cases) which contains an AspectJ pointcut expression,
e.g.:
JoinPointMatcher jpm = new
JoinPointMatcher("within(patterntesting..*)");
At any join point, you can ask JoinPointMatcher whether or not it
matches:
if( jpm.matches(thisJoinPoint)) ...
Here's an aspect that allows runtime configuration using this
mechanism:
aspect DynamicPointcutConstructionExample {
private static JoinPointMatcher jpm;
public void setPointcutExpression(String pointcutExpr) {
jpm = new JoinPointMatcher(pointcutExpr);
}
// this pointcut is used to narrow down as far as possible at compile
time the set of places
// at which a dynamic pointcut could match (for efficiency)
pointcut scope() : within(org.xyz.foo);
before() : scope() && if(jpm.matches(thisJoinPoint)) {
System.out.println("I matched!!");
}
}
The consequence you pay for using dynamic pointcuts (I'm using the word
dynamic in analogy to the use of "dynamic" in DII, it may not be the
best
term) is that the pointcut matching is (very much) less efficient since
the jpm.match code is driven for every join point in the scope (whereas
the same pointcut specified at compile time would cause the advice to
execute exactly where it needs to with no additional overhead or
redundancy). If a dynamic pointcut proved to be too slow, you could
always
switch back to a traditional statically specified pc.
If you're using Spring with the above example, you can configure the
aspect with e.g.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd";>
<beans>
<!-- what follows is an example syntax for specifying a
factoryMethod,
I hope we end up with something very close to this in Spring
-->
<bean id="dynamicPointcutConstructionExample"
class="DynamicPointcutConstructionExample"
factoryMethod="aspectOf">
<property name="pointcutExpression">
execution(* *(..)) && this(Foo)
</property>
</bean>
</beans>
Spring will set the value of the pointcutExpression attribute when the
aspect is constructed. Many thanks are due to Rod Johnson for the
inspiration to look into this.
[For the AspectJ developers, here's how the prototype currently works:
JoinPointMatcher uses the PatternParser class to build a Pointcut
(simple).
I then added a new match method in the Pointcut hierarchy that takes a
JoinPoint instead of a shadow, and implemented match(JoinPoint) down
the
hierarchy to do the right thing. I had to add match(Class) methods to
TypePatterns too. All the changes were self-contained, and the logic
mirrors the matching logic for shadows.
Restrictions in the implementation are that you can't use cflow or
cflowbelow in a dynamic pointcut (matching is done solely on the
current
join point), you can't use if() (don't want to go off into code), and
you
can't provide context information (bind "this(foo)" to a parameter
"foo")
or refer to other pointcuts.
Essentially I've written a convenience class for writing a powerful
form
of if() pcds.
]
Love it? Hate it? Let me know...
Cheers, Adrian.
I know, I know, I digressed for a day - Back to 1.2rc2 and AJDT
tomorrow....
-- Adrian
Adrian_Colyer@xxxxxxxxxx
aspectj-users-admin@xxxxxxxxxxx wrote on 07/05/2004 09:17:35:
Hi,
On the Pattern Testing project (http://patterntesting.sf.net), we have
aspects that enforce some design rules. For example:
public abstract aspect AbstractDatabaseTestAspect
{
/**
* Specify what is application code that should be subject to the
* pattern test.
*
* Ex: <code>pointcut applicationCode():
within(patterntesting.*)</code>
*/
public abstract pointcut applicationCode();
/**
* Specify which classes are allowed to call JDBC.
*/
public abstract pointcut allowedCode();
/**
* Specify which JDBC calls are forbidden.
*/
pointcut forbiddenCalls() :
call(public * java.sql..*(..)) ||
call(public * javax.sql..*(..));
/**
* Raise error if violations found.
*/
declare error: (applicationCode() && forbiddenCalls()) &&
!allowedCode() :
"It is not allowed to use the JDBC API from here";
}
Now, the question is: How can we make the applicationCode and
allowedCode pointcuts configurable by the end users?
Of course one solution is to have create classes that extend the
abstract aspect. However that sounds complex when compared to simple
configuration data (the end users would need to create a project where
to put the code, etc).
Any idea?
Note: The solution we're using so far (but which I don't like because
it's tied to the build system) is to use Ant filters:
public aspect DatabaseTestAspect extends AbstractDatabaseTestAspect
{
public pointcut applicationCode() :
@maven.patterntesting.suite.java.database.applicationCode@;
public pointcut allowedCode() :
@maven.patterntesting.suite.java.database.allowedCode@;
}
Thanks
-Vincent
_______________________________________________
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
