[jboss-user] [JBoss AOP] - Re: The use of Hotswapping

flavia.rainone@jboss.com do-not-reply at jboss.com
Wed Oct 29 19:14:40 EDT 2008


JBoss AOP is a dynamic weaver because it allows you to weave in and out aspects at runtime. How it does this behind the scenes depends on the mode you run it:

-no hotswap (regardless of whether you use aopc or loadtime weaving) it will add calls to empty invocations at the points you have prepared for dynamic weaving. At runtime, when you add aspects to those points, it will just add those aspects ot the invocation stack, without changing any code, as all the needed changes have already been performed.

-hotswap JBoss AOP will add only the auxiliary methods and fields to perform interception of your prepared points. This means that you code grows a little bit bigger (not too much bigger) compared with the unweaved version, but you won't have loss of performance, as your control flow is unchanged. When you add/remove aspects at runtime, JBoss AOP will recompile the affected classes, changing the control flow of the affected points, and reload them. This step is what we call hotswap.

In either case, you want to prepare specific points of your applications that you want to be target of runtime operations. Hotswap brings in great advantage because it won't cause any performance overhead to your application in the absence of aspects. That said, if you plan to have your points always intercepted (i.e., there will always be one or more aspects applied to the prepared points), there is no gain in using hotswap. You won't be able of taking advantage of the fact that your code runs faster in the absence of aspects, because there will always be at least one aspect performing interception on those points. On the other hand, if you think that at some moments of your application execution there will be one or more prepared joinpoints not being intercepted, then hotswap is the best choice.

IMO, the dynamic nature of JBoss AOP can be very handy in the scenario you described. It is not about being able of changing your application code without recompilation. Think about it, how can you garantee consistency if there is code calling a method and suddenly you remove a method?

It is about being able of changing your application at runtime. You can easily write a thread that watches a deployment directory or something. At this directory you deploy and undeploy a file containing the new security rules. This thread process the new rules and performs the changes by adding and removing aspects. Or, it may be the case of not using dynamic AOP at all. You can have a Security aspect running all the time, and this thread just reconfigures this aspect setting the new properties on it. It depends on the needs of your application.

If you want maximum flexibility, you can support deployment of aspects at this deployment directory. You can just load jars containing your security aspects and jboss-aop.xml files when such a jar file gets deployed. and remove those aspects when the jar gets undeployed. This is more or less what we do in JBoss AS, and this will allow you to write new code (the aspects), compile this code, package it and insert it into your running application, without having to recompile your entire application.

Finally, note that you are not stuck with a deployment directory. This is only one possibility. You can also allow configurations by some GUI instead of using a deploy directory, or having a thread paying attention to somethinig else in order to determine when to perform dynamic AOP operations.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4185560#4185560

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4185560

More information about the jboss-user mailing list