Hi Yim,
to my knowledge, you can tell the obfuscator to not touch specific classes/classNames/methods, which are part of the external API.
Velicity uses java objects placed in the context under a specific keyName, which are then accessed in the template with the $keyName as a reference. $keyName alone would insert the output of the toString() method (of the Object class, which may have been overriden by any subclass).
You may also reference any method of a context object, or implicetely bean getter methods; aka. $keyName.getMyValue() is the same as $keyName.myValue through the velocity reflection implementation. Also Collection methods (iterator) are implicetely used in the #foreach directive.
So when you use an obfuscator, you have to clearly define the API between your context classes and the template designer. These method names need to be left untouched.
IMHO, this should be clear to anyone using an obfuscator and knowing the java reflect API.
Thx, but in practice the interface between velocity and the API of my project is not that statics, due to various refactoring, I wish to improve the build time check as much as possible.
I have also think about adding unittest for this. However, it is hard to run unittest base on obfuscated build. And it is hard to tell which method have error in unittest of obfuscated build
Yeah... this should be what I looking for, would you recommend pointer of velecity javadoc of doing that?
Aha, here you are adressing something else as java class obfuscation.
You seem to want to obfuscate the template... maybe you should check if the AST-node representation of templates can be serialized and use your own resource loader taking the serialized version instead of the text template...
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
