Cross Cutting Concerns and dm Server

[johras]

I am thinking about how AOP stuff that spans multiple modules and perhaps even packages that are not exported will work in dm Server?

Will I have to think different about how to implement these kind of things when switching to dm Server or will there be any magic support for this?

/Johan

[robh]

Johan,

Are you thinking of using Spring AOP or AspectJ? Will you be using load or compile-time weaving if using AspectJ?

Regards,

Rob

[johras]

We are currently using a proxy based approach BUT this is not important, we can use any AOP technology. We have simply identified this as a potential problem. Since dm Server is an Enterprise OSGi solution I was hoping that there perhaps was some kind of solution or practices to get around this.

Can switching to AspectJ (loadtime or compile time) help me in any way?

Basically, our app is already divided into separate modules but wired together in one big application context. I am interested in knowing what will happen when I split this into multiple contexts (with different class-loaders)?

Do I have to have my packages exported for the weaving to work?

Best Regards

/Johan

[robh]

Johan,

If you are using a proxy-based approach then you need only export the package(s) of the interfaces implemented by the proxy. The interfaces of any aspects do not need to be exported when used within the module in which they are defined.

However, if you want to define an aspect/advisor/advice in one module and use it from another, then your aspect module will have to export the relevant package. For example, if I had a class com.myapp.aspects.InvocationPerformanceMonitor in module A, and I wanted to use that from module B, module A would have an export for com.myapp.aspects and B would have an import for com.myapp.aspects.

For weaving-based approaches, the only real difference is that the weaving will introduce new type dependencies (in org.aspectj.*) so your woven modules will need more import packages than normal.

In general, AOP should not affect your modules in any unusual ways - you'll just need to make sure that you have the relevant imports for any types you are touching.

You may encounter a problem when using reflective code as you might end up touching types you don't intend to. Typically, this is easy to work around - either add in some more imports or, more likely, code your reflection in a more guarded fashion.

Regards,

Rob

[Skippy]

Hi Rob,

I thought I'd understood what you meant - and then I tried it...

I'm trying to intercept a method declared in an interface contained in module A with an aspect declared in module B.

I needed to export the package containing the interface from module A so that the advice for an aspect defined in module B is satisfied, but the methods on the interface (in module A) are not being intercepted. If I export the aspect from module B and try to import it into module A, I then get (surprise, surprise!) a cyclic dependency error.

So, if you wanted to intercept a method call on a method defined in an interface in module A by an aspect defined in module B using Spring AOP (i.e. pure proxy-based AOP), what do you need to export from either / each module?

For the sake of completeness, it all works perfectly when the interface and aspect are in the same module, so perhaps I am going about this in the wrong way?

Cheers,
Skippy