JoyAop is a dynamic AOP framework for Java, based on the CGLIB2 proxies.

Some features of JoyAop:
  * Support the concept of abstract schema invented by Rickard Oberg.
  * Support pointcut composition, and joinpoint can be picked by interface and regular expression currently.
  * The proxies are serializable.
  * Different deployment scopes for the aspects: JVM, class, instance and thread.
  * Support joinpoint parameters for the aspects.
  * Support interceptor precedence.
  * Test friendly. With the extension mock objects, the abstract aspects can be easily test.
  * Integrate with other libraries, such as PicoContainer, Hibernate, etc.
      
Homepage: http://joyaop.sourceforge.net

Some questions:

1) In what way does JoyAop integrate with PicoContainer?
2) Would you consider implementing the aopalliance API? (That would make it easier for NanoContainer to integrate with JoyAop).

Cheers,
Aslak

Hi Aslak.

1) All the interceptors and mixins could be instantiated by PicoContainer. The code is located in the extension dir, but it's not elegant maybe. Besides, I found that PicoContainer1.1 prohibit registering abstract class, so I have to wrap the abstract ones before they are registered to the container.
2) I will read the aopalliance APIs, but I haven't look the NanoContainer's implementation yet, I will do it ASAP:)

Shen

JoyAop now supports the MethodInterceptor of the AOP Alliance.

http://joyaop.sourceforge.net/tutorial.html#_Toc85540195

http://prdownloads.sourceforge.net/joyaop/joyaop-1.0-beta2.zip?download

Personally, I really don't like the term "abstract schema" as applied to what Rickard has been doing. Being a data / EJB guy, I associate the term "schema" primarily with database schemas (which has nothing to do with the concept at hand), and "abstract schema" to the EJB construct of the same name.

I think we should brainstorm for a better name. I'd suggest "type-safe interceptor" personally. Rickard, Rod, Shen, any other suggestions / criticisms / corrections?

-Patrick

--
Patrick Linskey
SolarMetric Inc.

Patrick

Good question. I don't feel 100% happy with the name either, but as it's Rickard's concept, I'm reluctant to rename it. It also bothers me that following consistent naming conventions the Spring class that implements this would be called AbstractSchemaAdviceFactory: beginning the name of a concrete class with "Abstract" is a bit strange.

"TypeSafeInterceptor" implies that it is an interceptor, which could be confusing in frameworks like Spring and DynAOP (and now JoyAop) that implement AOP Alliance APIs. Of course it can do interception, but such classes also often do introduction. TypeSafeAdvice might be better. But I think type safety is the central issue, and it makes sense to get that in the name. IMO the "abstract" element just comes in due to the only workable implementation strategy in pure Java, and I'd happily drop the "schema".

I did a first cut at implementing this in Spring following JAOO, after talking to Rickard and hearing his presentation. Spring's implementation of this will be shipped in 1.2, although I'll check it into the sandbox earlier. It doesn't need any modifications to the Spring AOP core.

Rgds
Rod

Ask Martin Fowler. ;)

Bob

Seriously though, how about "template advice" (given that it utilizes the template design pattern)?

+1

As alawys, Bob is right on target. Especially that the delegation can be syntactically implemented via 1.5 templates. I remember the awkward feeling that I had when Rickard mentioned in his blog he'd found no clean way of delegating, so he basically suggested repeating the (unqualified) method call.

Personally, I really don't like the term "abstract schema" as applied to what Rickard has been doing.

I agree but for a different reason. The original name "abstract schema" in the EJB2 spec was an indirection between the EJB name and the real DB schema. And as such, it was already a terrible name sinec it had nothing to do with Java and nothing to do with databases.

--
Cedric

I have absolutely zero problems with finding a new name for the idea I outlined. When I had the initial idea it was just a matter of taking the "abstract schema" notion from EJB one step further, but as Cedric noted it was a bad idea even at that stage.

Terminology is less important than the idea itself, so if anyone has better suggestions go for it.