My use case is to log every method call on an object.
After adding a method interceptor on the target object, I call the method Foo. This method Foo calls a method Bar. Only the method Foo will be logged.
class MyClass {
public void Foo() {Bar();}
public void Bar() {}
}
Reading the Spring documentation, I have found a sentence that explained why I cannot implement what I want. From Spring documentation (page 146):
Please note that in both cases a target method implementation that calls
other methods on the target object will not be advised.
Am I missing something here? Or is this really a Spring limitation?
A start of solution...
http://www.digizenstudio.com/blog/2007/05/29/the-self-calling-limitation-in-spring-aop-and-one-unintrusive-solution/
EDIT
Finally, I decided to switch to Castle AOP. They propose a class proxy that feets my needs.
You could use AspectJ weaving that will not have any such limitations.
Related
I'm trying to create a generic function in grails that will allow me to specify a class and function name, and intercept any function calls based on that criteria:
getSomeClass().metaClass.invokeMethod = { String methodName, args ->
MetaMethod someAction = getSomeClass().metaClass.getMetaMethod(methodName, args)
def result = someAction.invoke(delegate, args)
if (methodName==getSomeMethodName())
intercept(args, result)
return result
}
This works for POGO, and domain classes, but does not seem to work for controller classes. While I'm fully aware there are Controller interceptors and filters available in Grails, these don't really centralise what I'm trying to achieve, and was trying to create a simple generic function for some centralised behaviour
Any guidance on why this doesn't work on Controllers would be appreciated, thanks
Your approach will work for method calls that are made through the Groovy metaclass mechanism, but in Grails 2 this doesn't apply to controller actions - they're called using normal Java reflection (java.lang.reflect.Method.invoke), and therefore your custom invokeMethod is bypassed.
If you want an AOP mechanism that'll work for calls from Java as well as from Groovy you'll probably have to use something like AspectJ load-time weaving. Spring's proxy-based AOP may work but the Grails 2 controller system relies on the action methods having a particular #Action annotation (which is added at compile time by an AST transformation) and I don't know whether Spring AOP proxies preserve method annotations from the target class on the generated proxy methods.
Could it be that MyController.metaClass.invokeMethod is overwritten by the grails framework after your definition?
Have you tried to check the content of MyController.metaClass.invokeMethod through reflection?
How do I replace methods of an existing java class (GrailsDataBinder in my case).
I read that method calls for java classes doesnt go through invokeMethod, and hence it doesn't work, but I think there would be some solution.
I just tried this
GrailsDataBinder.metaClass.static.createBinder = {Object target, String objectName ->
throw new RuntimeException()
}
And this
GrailsDataBinder.class.metaClass.static.createBinder = {Object target, String
objectName -> throw new RuntimeException()
}
But that did not seem to have replaced the method, as my closure isn't being invoked, but instead the original method executes.
update
I just found that the closure is being executed if I call the createBinder from the test class itself - so it works and method is replaced
void testDataBinder() {
GrailsDataBinder.createBinder(null, null)
}
However When it is invoked from DataBindingUtils, it always executes original method (DataBindingUtils is also a java class)
Following is the code inside DataBindingUtils that invokes the method.
binder = GrailsDataBinder.createBinder(object, object.getClass().getName());
Note : There are some similar questions asked earlier, but none of them have worked for me.
This is disappointing once you see the power of Groovy. However, as you already know, many of the cool metaclass etc. features available in Groovy simply don't work as you would like on Java classes.
If you are trying to override, stub or mock stuff on a Java class for unit testing etc., I advise looking into Spock, because it uses 'magic' that actually works on Java classes also.
If you are try to override methods for some other reason, you should try extending the Java class with a Groovy class or 'wrapping' the Java class with a Groovy class to gain the metaclass features you want when external classes call you classes methods. Unfortunately this still won't allow you to intercept calls that the Java class makes to itself.
How to declare a method inside a closure.Or which is better to use method or closure.
I have a closure and in that closure i have a method to call and i defined method as
def getBindedGenes(Long colId) {
........
}
But when i used codenarc plugin for code review it is showing the rule as GrailsPublicControllerMethod and the message as The Grails controller has a public method getBindedGenes. This should be a closure property or moved
What is the cause and what is happening exactly.
Thanks in advance
I think CodeNarc is warning you that your controller actions must be public closures, not public methods. Given that you can't use a public controller method as an action, there's probably no good reason to have one.
Grails 2.0 Update
Since Grails 2.0, public methods of controllers can be used as actions, and if fact, it is now recommended to use methods instead of closures.
Android requires that all Activity sub-classes invoke super methods from their lifecycle methods. An exception is thrown if the super method is not invoked. Why does Android use a RuntimeException mechanism to force super methods to be called. Why does it not use the 'Template' design pattern so that super methods get executed automatically before the child methods. For example onDestroy() can be handled as follows :-
Class Activity{
public void onDestroyFrmwork()
{
//do whatever the super onDestroy() method has to do
onDestroy();//this will invoke the subclass method.
}
public void onDestroy()
{
//empty. will get overridden by subclasses.
}
}
I know I am answering this question 11 months after it was asked. I guess the reason is that the order of calling the super method cannot be determined in advance. For example, I might want to do my clean up before calling super.onDestroy(), after super.onDestroy() or even mix it up like follows:
#Override
protected void onDestroy() {
// Do some initial clean-up
preDestroy();
//Then call super
super.onDestroy();
//In the end do some final clean-up
postDestroy();
}
This example is for the sake of argument; but I'm sure you would come across real world examples if you look hard enough.
This kind of mixed ordering would be hard to achieve using Template design pattern.
Your application won't work correctly if you don't call the superclass methods, so the API throws a RuntimeException to make sure you don't forget to do so.
Everytime I ask anyone what the Spring Framework is or what it does, they simply say to me, you remember that Hollywood principle right "Don't call me, I will call you", that's exactly what Spring Framework does.
What should I make out of this?
It means that a class doesn't manually instantiate the components that it depends on -- something (such as Spring's IoC context) gives the class an instance of each component that it needs. This is usually done either via setters for each component, or a constructor that takes all those components.
Basically instead of a class doing manual instantiation by itself:
public class Foo {
private Bar bar;
public void doStuff() {
bar = new BarImplementation();
bar.doMoreStuff();
}
}
IoC injects the dependency Bar into Foo, so that when you get a Foo object from the context, you know it's ready to use.
public class Foo {
private Bar bar;
public void setBar(Bar bar) { this.bar = bar; }
public void doStuff() {
// bar's already been set by the time this is called!
bar.doMoreStuff();
}
}
You didn't manually instantiate Bar, instead your configuration files (such as Spring XML) set it for you. Additionally, Foo is no longer tied to BarImplementation. Using interfaces allows you to insert different implementations, including mocks used for testing.
Sometimes callback models are more efficient, especially with anything to do with parsing
if you imagine the hollywood situation, its way more efficient for the "casting agent" to call everyone once they know who they are going to cast (or even not call) rather than having to keep taking calls from every applicant wanting an update.
Callbacks. :P That's what that means for me. Callbacks are functions that wait to be called.
See http://en.wikipedia.org/wiki/Inversion_of_Control
Spring does other things too but IoC/Dependency injection seems to be the most noted feature. It can help to make a system less coupled and more flexible.