Ok! Yes sure!

On Feb 26, 2018 20:31, "Andy Clement" <andrew.clem...@gmail.com> wrote:

> I did do some initial exploration work and it turned out to be bigger
> impact than I’d hoped. Doesn’t mean it won’t happen - just that it’ll take
> longer. If I did get you a snapshot build with prototype code in it, would
> you be able to try it out and see if it behaves in your situation?
>
> cheers,
> Andy
>
> > On Feb 26, 2018, at 4:41 AM, Fabian Bergmark <fabian.bergm...@gmail.com>
> wrote:
> >
> > Any progress?
> >
> > Cheers,
> > Fabian
> >
> > 2018-01-10 19:48 GMT+01:00 Andy Clement <andrew.clem...@gmail.com>:
> >> The proper optimization here is to use the LDC byte code that takes a
> >> constant class, rather than the string variant and then class loading.
> The
> >> original AspectJ used the string form because LDC didn't take a class
> >> originally.  Over the years a few places have been updated but not
> >> everywhere ( thisEnclosingJoinPoint is one of them that hasn't been
> done I
> >> think). Let me have a look at what I can do. For a while we had to
> tolerate
> >> both modes because LDC class was quite new, but it has been there so
> long
> >> now I think we can assume you are on a JVM that will have it.
> >>
> >> cheers,
> >> Andy
> >>
> >>
> >> On 10 January 2018 at 01:42, Fabian Bergmark <fabian.bergm...@gmail.com
> >
> >> wrote:
> >>>
> >>> I'm using both AspectJ and Proguard in a project. On of my aspects
> >>> inserts MDC-information in logging messages, including source location
> >>> and method:
> >>>
> >>> void around() : call(void org.slf4j.Logger.trace(..)) || call(void
> >>> org.slf4j.Logger.debug(..)) || call(void org.slf4j.Logger.info(..)) ||
> >>> call(void org.slf4j.Logger.warn(..)) || call(void
> >>> org.slf4j.Logger.error(..)) {
> >>>        try (MDC.MDCCloseable c3 =
> >>> MDC.putCloseable("logging_aspect::location",
> >>> thisJoinPoint.getSourceLocation().toString());
> >>>              MDC.MDCCloseable c4 =
> >>> MDC.putCloseable("logging_aspect::method",
> >>> thisEnclosingJoinPointStaticPart.getSignature().toString())) {
> >>>            proceed();
> >>>        }
> >>>    }
> >>>
> >>> However, when enabling obfuscation in proguard, this results in log
> >>> messages like:
> >>>
> >>> "mdc" : {
> >>>    "logging_aspect::method" : "void
> >>>
> >>> java.lang.ClassNotFoundException.onCreateConnectionChannelRespo
> nse(ClassNotFoundException,
> >>> CreateConnectionChannelError, ConnectionStatus)",
> >>>    "logging_aspect::location" : "File.java:299"
> >>> }
> >>>
> >>> I think there should be a way to access the Signature at the time of
> >>> compilation. This would also be faster (?) than looking up classes
> >>> during runtime.
> >>> _______________________________________________
> >>> aspectj-users mailing list
> >>> aspectj-users@eclipse.org
> >>> To change your delivery options, retrieve your password, or unsubscribe
> >>> from this list, visit
> >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>
> >>
> >>
> >> _______________________________________________
> >> aspectj-users mailing list
> >> aspectj-users@eclipse.org
> >> To change your delivery options, retrieve your password, or unsubscribe
> from
> >> this list, visit
> >> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@eclipse.org
> > To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Reply via email to