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 <[email protected]>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" <[email protected]> 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 >> [email protected] >> http://mailman.qos.ch/mailman/listinfo/logback-user >> > > _______________________________________________ > Logback-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user >
_______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
