That said, I think I was a bit to fast in hitting the reply button the other day. As you stated, the “call” pointcut that I suggested will not work, because the enclosing code is not available at compile time. Someone may think that the “execution” pointcut would solve this problem, but as you pointed out that will not work either, because when the pointcut traps the thread of execution it is already inside the method itself. Or more formally “execution(void m()) && withincode(void m()) is the same as execution(void m())” as it is expressed in the AspectJ Development Guide.

So I guess that we are left with load time weaving. One disadvantage is that you must manipulate the runtime that your library is deployed in, e.g. by using an agent or custom class loader, see the AspectJ Development Guide for details. If you are working in a Spring environment, you may find Load time weaving in Spring helpful.

thank you for responding me. A clear and esaustive answer, very useful for me.

I don’t know much of AspectJ but I have a question about the call join-point. As you have showed I have to use the ‘Call’ joint-point matching within the pointcuts. What I know (if I’m not wrong obviously) is that in the case of the call joint-point the weaver weaves only the method invocation locations and therefore I have to weave (compile) also the clients of my library otherwise no advice could be inserted between my-clients and my-library.

As an ‘alternative’ I can use the ‘execution’ join-point, in this case the advice would be available at ‘runtime’ (no need to weave clients, the method body is weaved instead) but in this case it can’t work neither ( I believe ) because you can’t express conditions on the callers.

Therefore my conclusion is that there is no real help from aspectj when:
- you need a ‘runtime’ policy enforcement
- you don’t control your clients (no possibility to weave them)

What I don’t understand is that why I need to apply a ‘policy enforcement’ to code that I already own(compile)?
Would be more useful if I could apply policies at clients that I do not control and I don’t know (runtime)?

Is that correct or I’m doing something wrong?

Thank you very much again.

First, the simplest solution is to use a default (empty) access modifier for the objects that the factory creates. In order make that possible, you have to place the classes that the factory instantiates in the same package as the implementation of the factory. The advantage being that the constructors are not accessible from any other package, and thus forcing clients to use the factory. Consequently, the architecture is enforced without any aspects.

Secondly, if your colleagues rebuild the entire system including your library, you can still use static compile time enforcement by using some appropriate pointcuts. For example, if your library’s public api is in the public package and its implementation is in the internal package:

@Pointcut("within(*..*.public..*)")
public void withinPublic() {}

@Pointcut("call(* *..*.internal..*(..))")
public void callInternal(){}

// Prevent all but the libraries public api to call the internal implementation
@DeclareError("!withinPublic() && callInternal()")
private static final String CLIENTS_MUST_NOT_USE_INTERNAL_PACKAGES = "Library internal methods must not be accessed";

Lastly, if you deliver binaries, you could weave your aspects during compile time and then add some notification in runtime like you suggest. Using the same pointcuts as above, you could for example implement a before advice:

@Before("!withinPublic() && callInternal()")
public void handleAccessViolationAdvice(JoinPoint.EnclosingStaticPart callerContext) {
    String message = "Illegal method call from " + callerContext.getSourceLocation().toString();
    // notify the caller about the architectural violation by throwing exception, log error, etc
}

Yet again, depending on your project, you should also consider whether or not you should weave in the aspect for production builds. Alternatively, you may choose to implement a different kind of notification when the application runs in production. The reason being that if your library is used by some untested code, it may blow up the entire application if the advice throws an exception.

first of all thank you for this very good article.

I have question:

I’m developing a library to be used within the company where I work and, I want to enforce ‘limiting collaboration’ and ‘factory pattern’ but I have control only on my library and not on the clients of my library, therefore in my case the policies can’t be applied on compile time but must be evaluated only in runtime time.

My question is: can I enforce runtime policies using AspectJ weaving only my library? Can it work? or it’s necessary to weave both clients + my library?

Thank you very much again.

It was a long time ago since I last used Ant. As a matter of fact I have never used it together with AspectJ. Nevertheless, here are some thoughts:

The normal javac compiler does not weave the aspects into the source code, so this must be handled separately (that’s why I provided the aspectj-maven-plugin in the blog post). In your case, I guess that you have to run the AjcTask or the Ajc11CompilerAdapter as described in AspectJ Ant Tasks of The AspectJ Development Environment Guide.

You can also search the AspectJ User Mailing Lists to see if anyone else has similar problems or post a question there if you do not find the answer you are looking for.

Good luck!

I was able to do compile time weaving with maven…but with ant, it creates class files from .aj files. However it doesn’t enforce the aspect during compile time

My ant script..

After above task, i compile source files using javac task…

Any guess what i could be doing wrong? I want to enforce aspects during compile time .

http://williamlouth.wordpress.com/2010/06/09/architectural-enforcement-with-opencore-probes/

The general idea should be to keep as much of the architectural aspects in the code as possible. There are frameworks attempting to do this such as Qi4J http://www.qi4j.org/ which I find really interesting.

@William: Exciting, I am looking forward to reading your post.

@Simone: Do you have any good links with hasField and hasMethod that you mentioned? I would like to see a working example, because I am not previously familiar with them.

@Hagai: Thank you for the link. The point I am trying to make is that aspects can be used as one tool for architectural enforcement. I deliberately chose a simple example with clear, well-defined rules for illustrational purposes. Agreeably, separating different packages into separate projects and monitoring their dependencies is a good way to promote good architecture, especially if the cuts are as obvious as in this case.

Other than static error/warning delcaration, we often emply also runtime checks, that will throw an exception during test execution, in the case where, for example, from a view we “reach” a DAO without going thru the service. Runtime checks can express more complex rules, cause there are situations where the compiler alone cannot determine the application state correctly, while at runtime you have much better support. Since code should be compiled AND tested before checking it in, runtime checks should protect the code as well as static checks.

Three Degrees of Separation in APM
http://williamlouth.wordpress.com/2010/03/07/three-degrees-of-separation-in-apm/

I will post a blog entry next week demonstrating how this [your use case] can be easily achieved a number of ways today using events, stack and tierpoint probes provider extensions.

By the way our probe naming is not coupled to Java so we can do this for any JVM supported language including JRuby, Jython, SQL, even HTTP requests. You could even use additional context information related to the current activity.

Have you thought about packaging this as a plug-in and present the information visually in Hudson or Sonar? I think this kind of functionality practically begs to be encapsulated in a plug-in that is easily configurable and resusable across projects.

Magnus

@William: Interesting project. I guess one would track the package names of the executing classes by using the BEFORE_BEGIN and AFTER_END events (similar to an around advice, but using instrumentation rather than aspects), and throw an exception if any architectural rule is violated?

@Matt and @William: I find your articles interesting and they both address my key concern; automation of architectural enforcement. From my point of view, there is an advantage of using compile time verification rather than runtime verification. It enables early architectural enforcement of the entire code base. In other words, the architectural enforcement is decoupled from the need of executing code, let it be tests or the application itself. This would probably not be an issue if project is well managed, but if the project is immature, has poor test coverage or lots of dead code, it is possible that architectural violations will pass unnoticed.

I wrote an article a while back titled “Listening to software as it executes”
http://williamlouth.wordpress.com/2009/01/22/listening-to-software-as-it-executes/

Our approach is much more dynamic though in the example the underlying instrumentation technology is the same but it need not be.

William

M