Hello Ceki,<div><br></div><div>Thanks for that information. After looking into your suggestions, it seems the most straightforward way to intercept this is by accessing <b>PatternLayout.defaultConverterMap</b> at application startup to install either an overriding or alternative converter in the <i>Map<String,String></i>, most likely by basing the implementation on <b>ClassOfCallerConverter</b>.</div>
<div><br></div><div>However, this led me onto the conversion "<b>%ex</b>" which seems to be implemented by <b>ThrowableProxyConverter</b>, and I'm guessing I need to do some work here too: I'm guessing I need to provide an implementation of <b>IThrowableProxy</b>, such as a subclass of <b>ThrowableProxy</b> that overrides <b>getStackTraceElementProxyArray()</b>? Here, I'm guessing I'd need to call <i>super.getStackTraceElementProxyArray()</i> and build an equivalent array of proxies whenever the underlying stack trace elements refer to a package I know to be obfuscated. Would that be correct? If so, where and how can I install my implementation of <b>IThrowableProxy</b>?</div>
<div><br></div><div>As for the example you cited with ConversionRuleAction, I'm guessing it's the "cleanest" approach to the API (no assumptions about layout or encoder) but requiring the use of Joran/XML configuration?</div>
<div><br></div><div>Thanks again,<br>Christopher</div><div><br>
<br><br><div class="gmail_quote">On 5 December 2011 13:49, ceki <span dir="ltr"><<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Christopher,<br>
<br>
It think writing a custom conversion specifier [1] is really the way<br>
to go here. Let's assume the converter is called<br>
ObfuscatedClassConverter. You would place the mapping in<br>
ObfuscatedClassConverter or in some other resource that<br>
ObfuscatedClassConverter looks up at run time. Once<br>
ObfuscatedClassConverter has the class mapping it would output caller<br>
class name similar to what ClassOfCallerConverter [2] does.<br>
<br>
As discussed in [1], you can register a conversion specifier in a<br>
configuration file. You can also register a specifier programmatically<br>
by populating the pattern rule registry. See ConversionRuleAction [3]<br>
for details. Alternatively, you could also access PatternLayout's<br>
defaultConverterMap directly.<br>
<br>
HTH,<br>
<br>
[1] <a href="http://logback.qos.ch/manual/layouts.html#customConversionSpecifier" target="_blank">http://logback.qos.ch/manual/<u></u>layouts.html#<u></u>customConversionSpecifier</a><br>
[2] <a href="http://logback.qos.ch/xref/ch/qos/logback/classic/pattern/ClassOfCallerConverter.html" target="_blank">http://logback.qos.ch/xref/ch/<u></u>qos/logback/classic/pattern/<u></u>ClassOfCallerConverter.html</a><br>
[3] <a href="http://logback.qos.ch/xref/ch/qos/logback/core/joran/action/ConversionRuleAction.html" target="_blank">http://logback.qos.ch/xref/ch/<u></u>qos/logback/core/joran/action/<u></u>ConversionRuleAction.html</a><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Ceki<br>
<a href="http://twitter.com/#!/ceki" target="_blank">http://twitter.com/#!/ceki</a></font></span><div><div class="h5"><br>
<br>
On <a href="tel:05.12.2011%2012" value="+33512201112" target="_blank">05.12.2011 12</a>:26, Christopher BROWN wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hello,<br>
<br>
I've not yet found an answer to my question (I did get some suggestions<br>
back but no solution), so if anyone can help...<br>
<br>
So far, by investigating myself, it appears that I could either replace<br>
PatternLayout (but that means basically forking code with all the<br>
associated drawbacks) or use something like ClassicConverter (but I<br>
didn't see how do override just the parts of the layout I need, the ANSI<br>
colour example wraps the whole line... maybe I missed something). The<br>
conversion word "replace" doesn't seem to be a scalable solution (and<br>
furthermore, it's static whereas the application is OSGi-based therefore<br>
JARs can be reloaded at runtime with modified contents).<br>
<br>
I'm stuck!<br>
<br>
One suggestion I did get back was to keep the obfuscated code mapping<br>
outside of the runtime environment, and decode "in house" stacktraces<br>
when a customer sends us log files containing stacktraces with<br>
obfuscated class/method names. This suggestion does not provide the<br>
solution, as we can't be sure that we match versions (version reported<br>
by customer and version of class/method name mappings), so the "package<br>
the mapping file in the JAR" is still the most reliable from that point<br>
of view.<br>
<br>
Also, another reply pointed out that if the mapping is in the JAR, then<br>
it effectively renders useless the obfuscation: regarding that remark,<br>
yes, it makes it easier to restore the original source code, however the<br>
aim isn't a naive "total security" approach, it's primarily to<br>
discourage casual use and most of all, to encourage our customers not to<br>
link to obfuscated code, as we deliver a public non-obfuscated API, and<br>
it's a way of discouraging people taking shortcuts (because they<br>
unfortunately do and they can end up making their own code more prone to<br>
breakage by fiddling with internals and by having things change during<br>
upgrades).<br>
<br>
So a solution remains relevant.<br>
<br>
Thanks,<br>
Christopher<br>
<br>
<br>
On 28 November 2011 16:31, Christopher BROWN <<a href="mailto:brown@reflexe.fr" target="_blank">brown@reflexe.fr</a><br></div></div><div class="im">
<mailto:<a href="mailto:brown@reflexe.fr" target="_blank">brown@reflexe.fr</a>>> wrote:<br>
<br>
Hello,<br>
<br>
What would be the best way to handle logging with logback when<br>
deploying obfuscated code?<br>
<br>
For example, with YGuard, when the obfuscator runs, it outputs a<br>
mapping file of obfuscated code (class names, method names, etc) to<br>
unobfuscated code. When a stacktrace or just any logging trace is<br>
output, the class/method names are obviously obfuscated. As it's<br>
possible to deploy this mapping with the code, say embedded in the<br>
same ".jar", all the information I would need is available.<br>
<br>
Without too much re-writing of code (default formatting with<br>
logback), what would be the best way to dynamically replace matching<br>
class/method names?<br>
<br>
Thanks,<br>
Christopher<br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Logback-user mailing list<br>
<a href="mailto:Logback-user@qos.ch" target="_blank">Logback-user@qos.ch</a><br>
<a href="http://mailman.qos.ch/mailman/listinfo/logback-user" target="_blank">http://mailman.qos.ch/mailman/<u></u>listinfo/logback-user</a><br>
</div></div></blockquote></div><br></div>