AspectJ and EJB

[HS Thomas]

Are there any "Cross-cutting concerns" or aspects in EJBs that you can use AspectJ for?
And does your book cover this?
regards

[Bhushan Jawle]

I think EJB implementation is a scaled down version of AOP as it frees developer from all the concurrency related issues or 'concerns' which otherwise might be 'cross weaved' in all the code.
May I start the list of 'Cross cutting concerns' with usual candidate logging.

[Valentin Crettaz]

Other crosscutting concerns in the EJB architecture are security management, transaction management, concurrency, etc. All of these are system-level concerns of an enterprise application that do not necessarly pertain to the business logic of an enterprise bean. The EJB specification requires EJB containers to take care of those "aspects" and offer those services "for free" to deployed beans. Containers are free to provide system-level services any way they want. This is often seen as a sort of service wrapper around the beans.

[Pradeep bhatt]

What is cross cuttings?

[Bhushan Jawle]

One that cuts across different parts of system. Might sound like jugglery of words but if you think of one such example (logging) that might clarify your doubt

[Valentin Crettaz]

A concern that is crosscutting is a concern that cannot be adequately localized in the units of modularity that current techniques (object-oriented, etc) provide. For instance, in an object-oriented system the natural unit of modularization is a class. When you have to write security-related code with an object-oriented programming language, such as Java or C++, you cannot cleanly modularize all your security concerns in a single class. You will have to scatter all your security code across all of the methods that need security checking. Thus, we call the security concern a crosscutting concern because it "cuts across" the boundaries of multiple classes. If you have to change your security policies, you will have to figure out all the methods that need to be changed and hope you don't miss anything or you may run the risk to break your system. This is the same story for transaction management, logging, tracing, profiling, etc... A good indicator is that as soon as you start writing the same code in different classes, you have a candidate aspect waiting to be fine-tuned.
You can also refer to the following post: https://coderanch.com/t/91667/java/Do-we-AOP
[ September 17, 2003: Message edited by: Valentin Crettaz ]

[Ramnivas Laddad]

Valentin and Bhushan already answered it quite well. Thanks.
One particular way you can use AspectJ with EJB is to enforce policies (chapter 6 of AspectJ in Action). This will help you catch violations of EJB restrictions such as no access to the file system or socket, no use of thread primitives, no use of non-final static variable, and so on. This will improve the quality of your code during development phase itself, instead of getting surprised by errant behavior of a deployed application. Further, these policy enforcement aspects are reusable that you can take from one project to another without any modifications.
-Ramnivas

[Lasse Koskela]

Originally posted by Ramnivas Laddad:
[QB]...One particular way you can use AspectJ with EJB is to enforce policies...

Could you elaborate this a little bit? How do you enforce the "don't use java.io.*" restriction, for example, and how does AspectJ notify the developer about this? During compilation or only at runtime?

[Pradeep bhatt]

Looks like the AspcetJ compiler does a lot of work. Is that the reason why it is slow?
One more question- Is the complier written in Java?

[Ramnivas Laddad]

Originally posted by Lasse Koskela:

Could you elaborate this a little bit? How do you enforce the "don't use java.io.*" restriction, for example, and how does AspectJ notify the developer about this? During compilation or only at runtime?

Lasse,
Here is an aspect from AspectJ in Action that enforces such restriction:

import javax.ejb.*;
public aspect DetectEJBViolations {
    pointcut uiCalls() : call(* java.awt.*+.*(..));
    declare error : uiCalls() && within(EnterpriseBean+)
: "UI calls are not allowed from EJB beans.\n See EJB 2.0 specification section 24.1.2";
    
    before() : uiCalls() && cflow(call(* EnterpriseBean+.*(..))) {
System.out.println("Detected call to AWT from enterprise bean");
System.out.println("See EJB 2.0 specification section 24.1.2");
Thread.dumpStack();
    }
    // Implementation of other programming restrictions:
    // Socket, file i/o, native library loading, keyboard input
    // thread methods access, reflection etc.
    pointcut staticMemberAccess() :
set(static * EnterpriseBean+.*);
    declare error : staticMemberAccess()
: "EJBs are not allowed to have nonfinal static variables.\n See EJB 2.0 specification section 24.1.2";
}

There are two ways the enforcement is implemented:

Compile-time through use of �declare error� and �declare warning� construct.

Runtime though use of advice. This one helps to catch the violating occuring in methods directly or indirectly called by a bean method.

-Ramnivas

[Lasse Koskela]

Whoa,
That was too much alien syntax for me to grasp at once
A couple of questions:
1) when you "declare error", does that translate to an exception being thrown? If so, where the class of the exception is specified?
2) was "EnterpriseBean+" some name you've specified yourself in somewhere or is it part of AspectJ?

[Ramnivas Laddad]

Lasse,
Yes, the syntax can be intimidating initially, but most developer get over it in a few hours. Chapter 3 of AspectJ in Action, section 3.3.3 contains all the details of "declare error".
In the DetectEJBViolations aspect, the declare error statement is saying: "Make it a compiler-time error if there is a join point matching a call to any method in any class (note the * indicating "any") or its subclasses (note the + indicating subclasses) in java.awt package made within javax.ejb.EnterpriseBean or its subclasses".
-Ramnivas

[Lasse Koskela]

Doh! I should've noticed the import statement...
Thanks, again, for the explanation.