Darren, Using ActionEvents is not desirable for the plugin either... today CloudStack lacks the ability for a component/plugin to associate itself to the life-cycle of an object. It would be ideal if there was a generic way to accomplish that... The contrail plugin wants to know about project creation and deletion. Projects need to be reflected in the contrail-api server; the project delete notification is necessary to understand that the project is not longer used.
When it comes to network objects it would also be nice if there could a for a component/plugin to associate itself with network creation / implementation... Currently there are calls from the NetworkManager to components such as firewall/LB/etc which should be optional. Ideally, i would like to have a common notification mechanism for a cloudstack object (e.g. project, network, nic). This could optionally allow a plugin to "veto" an operation and/or just get notified that it occurred. thanks, Pedro. On Oct 8, 2013, at 10:25 AM, Darren Shepherd wrote: > I'll take some time and review this code too. I already know there's > going to be a conflict with the stuff I did in the spring > modularization branch. Moving to full spring we have gotten rid of > the custom ACS AOP for the mgmt server. This code relies on that > framework so it will have to move to being a standard > org.aopalliance.intercept.MethodInteceptor. I don't particularly care > for the fact that functionally it being keyed off of ActionEvents (or > AOP in general). I'll need to review the code further to provide more > useful feedback, but just giving the heads up that the AOP stuff will > have to change a bit. > > Darren
