Hi Chris,

Keep the log stacktraces obfuscated. Then create a process that de-obfuscates the stack traces for YGuard. I'm not familiar with YGuard, so there could be something like this already.

ProGuard (another obfuscation package) has this with ReTrace.
http://proguard.sourceforge.net/index.html#/manual/retrace/introduction.html 

-- TJ

On Mon, Nov 28, 2011 at 10:50 AM, Chris Pratt <thechrispratt@gmail.com> wrote:

You do realize that if you supply the mapping file to the end user, there is really no reason to obfuscale the code in the first place.  They'll have everything they need to properly un-obfuscate and decompile it.
  (*Chris*)

On Nov 28, 2011 7:32 AM, "Christopher BROWN" <brown@reflexe.fr> wrote:
Hello,

What would be the best way to handle logging with logback when deploying obfuscated code?

For example, with YGuard, when the obfuscator runs, it outputs a mapping file of obfuscated code (class names, method names, etc) to unobfuscated code.  When a stacktrace or just any logging trace is output, the class/method names are obviously obfuscated.  As it's possible to deploy this mapping with the code, say embedded in the same ".jar", all the information I would need is available.

Without too much re-writing of code (default formatting with logback), what would be the best way to dynamically replace matching class/method names?

Thanks,
Christopher

_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user

_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user