AOP Alliance [ aopalliance.jar ]

aopalliance.jar
AOP 를 사용하기 위해서 필요한 라이브러리
Advice 용 Class 작성시 사용됨.
부언하기는  org.springframework.aop.MethodBeforeAdvice and AfterRunningAdvice  and ThrowsAdvice
위 세가지 Advice 를 하나로 묶음.
즉, 메서드 실행 전, 후 도는 예외박생 시점에 공통기능을 실행할 수 있다. 

http://www.jarfinder.com/
http://sourceforge.net/projects/aopalliance/

AOP Alliance (Java/J2EE AOP standards)

Motiviations

Aspect-Oriented Programming (AOP) is a programming technique that will be able to enhance several existing middleware environments (such as J2EE), or development environements (e.g. JBuilder, Eclipse).

Several projects now provide AOP-related techniques such as generic proxies, interceptors, or bytecode translators.

• ASM: a lightweight bytecode translator.
• AspectJ: an AO source-level weaver. New Language.
• AspectWerkz: an AO framework (bytecode-level dynamic weaver+configuration).
• BCEL: a bytecode translator.
• CGLIB: high-level API for class artifact manipulation and method interception.
• JAC: an AO middleware (bytecode-level dynamic weaver+configuration+aspects). Framework.
• Javassist: a bytecode translator with a high-level API.
• JBoss-AOP: interception and metadata-based AO framework.
• JMangler: a bytecode translator with a composition framework for translations.
• Nanning: an AO weaver (framework).
• Prose: an AO bytecode-level dynamic weaver (framework).
• ... and many others (email me to add a new one)

All these projects have their onw goals and speficities. However, several common basic components are still usefull (and sometimes required) to build a full AO system. For instance, a component that is able to add metadata on the base components, an interception framework, a component that is able to perform code translation in order to advice the classes, a weaver component, a configuration component, and so on.

To us, it would be great to be able to reuse different components coming from different projects to build a full AO system, and for three main reasons.

• Firstly, several components already exist and it would be stupid to rebuild them.
• Secondly, various implementation of the same component may be useful and be more-or-less suited depending on the environement. For instance:
  • the program tranformation can be done at a bytecode or a the source-code level, at compile or at run time, using an interception or a code insertion mechanism depending on the implementation of the component that translates the base program,
  • the weaver may be used within a standard Java context or within an EJB context, which may imply some implementation differencies
• Thirdly, having common interfaces and components would help in reusing aspects on different weaving environements... this will greatly improve sofware reusing.

For these reasons, we think that a standarization of the interfaces of the aspect-oriented components would be great and will bring great simplifications for the entire AOSD community, but also for all the communities that will to use AOP in a close future.