Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
DisabledFeatureProxy should proceed hashCode and equals methods to avoid breaking Spring ApplicationContext #196
Using GLU version 4.6.1
I find random errors in console server's logs.
I think DisabledFeatureProxy should proceed hashCode and equals methods to avoid breaking Spring ApplicationContext
475148 [Thread-7] ERROR org.codehaus.groovy.grails.commons.spring.ReloadAwareAutowireCapableBeanFactory - Destroy method on bean with name 'commandsService' threw an exception
Thanks for the report and the gist. I think your proposal looks good although I am just wondering if in the end all methods inherited from Object should not be "passed through" (toString, wait, notify, etc...).
I am just curious how you reproduce the problem so that I can make sure that the problem is fixed (I did not see this exception during my testing).
I don't think it is mandatory to let pass other methods from Object.class.
Found in code, 2 different conditions that leads to the usage of DisabledFeatureProxy
Are those conditions equivalent ?
On DisabledFeatureProxy implementation, I think the approche is to pass the Interface to be disabled in the DisabledFeatureProxy constructor, then the proxy should check if the invoked method's declaring class is the aforementioned Interface. If so, then throw the Exception, otherwise execute the method on itself.
In regards to your question "Are those conditions equivalent?", the answer is yes: one is for the console, the other one for the agent.
In regards to fixing the issue, I really need to know how to reproduce the problem in the first place. Otherwise I cannot test that the fix addresses the issue, no matter what the fix is.
added a commit
Jan 21, 2013
To reproduce, try to set the "commands" feature off by using
and trigger the Spring Application destroy by using command line console-cli.sh stop
I guess by reading the stacktrace that the destroy method will trigger the "postProcessBeforeDestruction" method of all DestructionAwareBeanPostProcessor.
If not, to reproduce, I suggest, you should ensure that the ApplicationContext contains such a DestructionAwareBeanPostProcessor (and maybe any BeanPostProcessor that will be triggered after the DisabledFeatureProxy is added to the Context).
Following your release, I tested on version 4.6.2 and did not encountered the bug.
Thanks a lot.