Hello Ceki,

Thanks for that information.  After looking into your suggestions, it seems the most straightforward way to intercept this is by accessing PatternLayout.defaultConverterMap at application startup to install either an overriding or alternative converter in the Map<String,String>, most likely by basing the implementation on ClassOfCallerConverter.

However, this led me onto the conversion "%ex" which seems to be implemented by ThrowableProxyConverter, and I'm guessing I need to do some work here too: I'm guessing I need to provide an implementation of IThrowableProxy, such as a subclass of ThrowableProxy that overrides getStackTraceElementProxyArray()?  Here, I'm guessing I'd need to call super.getStackTraceElementProxyArray() 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 IThrowableProxy?

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?

Thanks again,
Christopher



On 5 December 2011 13:49, ceki <ceki@qos.ch> wrote:
Hi Christopher,

It think writing a custom conversion specifier [1] is really the way
to go here.  Let's assume the converter is called
ObfuscatedClassConverter.  You would place the mapping in
ObfuscatedClassConverter or in some other resource that
ObfuscatedClassConverter looks up at run time. Once
ObfuscatedClassConverter has the class mapping it would output caller
class name similar to what ClassOfCallerConverter [2] does.

As discussed in [1], you can register a conversion specifier in a
configuration file. You can also register a specifier programmatically
by populating the pattern rule registry. See ConversionRuleAction [3]
for details. Alternatively, you could also access PatternLayout's
defaultConverterMap directly.

HTH,

[1] http://logback.qos.ch/manual/layouts.html#customConversionSpecifier
[2] http://logback.qos.ch/xref/ch/qos/logback/classic/pattern/ClassOfCallerConverter.html
[3] http://logback.qos.ch/xref/ch/qos/logback/core/joran/action/ConversionRuleAction.html

--
Ceki
http://twitter.com/#!/ceki


On 05.12.2011 12:26, Christopher BROWN wrote:
Hello,

I've not yet found an answer to my question (I did get some suggestions
back but no solution), so if anyone can help...

So far, by investigating myself, it appears that I could either replace
PatternLayout (but that means basically forking code with all the
associated drawbacks) or use something like ClassicConverter (but I
didn't see how do override just the parts of the layout I need, the ANSI
colour example wraps the whole line... maybe I missed something).  The
conversion word "replace" doesn't seem to be a scalable solution (and
furthermore, it's static whereas the application is OSGi-based therefore
JARs can be reloaded at runtime with modified contents).

I'm stuck!

One suggestion I did get back was to keep the obfuscated code mapping
outside of the runtime environment, and decode "in house" stacktraces
when a customer sends us log files containing stacktraces with
obfuscated class/method names.  This suggestion does not provide the
solution, as we can't be sure that we match versions (version reported
by customer and version of class/method name mappings), so the "package
the mapping file in the JAR" is still the most reliable from that point
of view.

Also, another reply pointed out that if the mapping is in the JAR, then
it effectively renders useless the obfuscation: regarding that remark,
yes, it makes it easier to restore the original source code, however the
aim isn't a naive "total security" approach, it's primarily to
discourage casual use and most of all, to encourage our customers not to
link to obfuscated code, as we deliver a public non-obfuscated API, and
it's a way of discouraging people taking shortcuts (because they
unfortunately do and they can end up making their own code more prone to
breakage by fiddling with internals and by having things change during
upgrades).

So a solution remains relevant.

Thanks,
Christopher


On 28 November 2011 16:31, Christopher BROWN <brown@reflexe.fr
<mailto: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