jknack
Not able to Register Spring Bean as Helper Object
We are creating a Spring bean with dependents injected as a Helper registration. This used to work previously, but in the latest version it is not working.
The issue is, in the DefaultHelperRegistry Class, registerDynamicHelper method is invoked to extract public methods of the class and register them as helpers. In previous implementation, the methods were checked for the return type like: CharSequence.class.isAssignableFrom(method.getReturnType())
But this condition is removed in the latest implementation. This causes all the internal methods of the class along with spring proxy methods to become eligible for registration. This can cause an issue down the line, but continuing, this condition fails: isTrue(overloaded.add(helperName), "name conflict found: " + helperName);
As there are multiple internal methods of spring proxy with same name. This causes the error being thrown and the handlebars object won't create. Either bring back the previous condition check for method registration or some interface to register the methods as helper.
We changed the return type to Object in Helper.java. This is required to increase handlebars.js compatibility and for better sub-expression evaluation (not need to test over Strings).
Wonder why do you have a proxy for a helper? Why can;t just inject dependencies to the helper?
We use CGlib + Spring bean. So there is no interface to the helper class. Even in the normal case, the objects will have basic methods of Object class like toString, clone, etc. All of them are being registered as helper.
On Fri 22 Jun, 2018, 9:17 PM Edgar Espina, [email protected] wrote:
We changed the return type to Object in Helper.java. This is required to increase handlebars.js compatibility and for better sub-expression evaluation (not need to test over Strings).
Wonder why do you have a proxy for a helper? Why can;t just inject dependencies to the helper?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jknack/handlebars.java/issues/641#issuecomment-399487701, or mute the thread https://github.com/notifications/unsubscribe-auth/Ah6Hx9cx7SjS_dw8uwoTCPN1ARvOF57Nks5t_RGtgaJpZM4Uz2GK .
We use CGlib + Spring bean. So there is no interface to the helper class.
yes, get it. My question is why a simple helper class need to be manipulated by CGlib? It shouldn't.
Even in the normal case, the objects will have basic methods of Object class like toString, clone, etc. All of them are being registered as helper.
We use .getDeclaredMethods(). Method from Object are not registered.
Do you know if CGlib methods are synthetic or have something to uniquely identify them?
We inject the service beans in the helper classes. There are certain helper methods required to fetch data. We are using handlebar as the spring view in our web application. The whole UI is generated using handlebar. So certain areas like checking user Authorization, generating headers for the pages etc are automated at view layer using helper.
CGlib generates proxy classes at runtime to replace the original class by writing bytes. Due to this all the methods, even base methods might be becoming declared methods.
On Sat 23 Jun, 2018, 12:12 AM Edgar Espina, [email protected] wrote:
We use CGlib + Spring bean. So there is no interface to the helper class.
yes, get it. My question is why a simple helper class need to be manipulated by CGlib? It shouldn't.
Even in the normal case, the objects will have basic methods of Object class like toString, clone, etc. All of them are being registered as helper.
We use .getDeclaredMethods(). Method from Object are not registered.
Do you know if CGlib methods are synthetic or have something to uniquely identify them?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jknack/handlebars.java/issues/641#issuecomment-399541769, or mute the thread https://github.com/notifications/unsubscribe-auth/Ah6Hx0hutyEVvdDl8mJcRnZ8aFBfFt3Cks5t_TqjgaJpZM4Uz2GK .
@jknack Any updates on this? Due to this we are not able to migrate to the latest version of Handlebars.
I'm sorry but if we can't easily identify a cglib runtime generated method, can't do much.
I won't change or revert this changes bc this how helpers and handlebar.js works.
On technical note, feel your helpers are doing lot more of what they should do (security, transactions, etc..). This is not the goal/intention of helpers.
registerDynamicHelper should probably check for Method.isSynthetic(). I'm not certain what flags CGLib sets, but this would help with many instances of this sort of unwanted registration, especially for languages like Groovy that append "hidden" methods like metaclass operations.
