AspectJ против toString () - PullRequest
Новая
       11

AspectJ против toString ()

1 голос
/ 19 июля 2009 

public pointcut myToString() : within(mypackage.*) 
&& execution(public String toString());

String around(): myToString(){
    System.out.println("myToString");
    return proceed();
}

Это работает, только если я переопределяю toString в классе, который я пытаюсь переплетать, есть ли способ заставить его работать на всех методах toString?

1 Ответ

4 голосов
/ 20 июля 2009

Это не сработает, потому что inside () соответствует только выполнению в вашем пакете, но вы наследуете метод toString (), если вы не объявили его явно.

Edit: я посмотрел, cflow тоже не будет работать. Я не вижу другого способа сделать это без переплетения времени загрузки, но это повлечет за собой запись всех вызовов toString (), что является очень плохой идеей. Вероятно, вам гораздо лучше просто объявить toString () во всех ваших методах с return super.toString () , чтобы ваш оригинальный pointcut работал (и если toString () никогда не вызывается, иначе вы не потеряете) ничего).

Если вы полны решимости придерживаться этого подхода, есть раздел документации aspectj , который поможет вам начать ткачество во время загрузки.

Обновление: еще один вариант - использовать Eclipse Detail Formatters . Они позволяют вам украшать методы toString () для целей отладки.

Оригинальный ответ: Вы можете попробовать использовать cflow для сопоставления с любой точкой соединения в потоке управления toString (). Заметьте, что я не смог проверить это, поэтому проверьте синтаксис (возможно, он также должен быть execute (), а не call (), хотя я точно не могу вспомнить). Например: 

public pointcut myToString() : cflow(call(String mypackage.*.toString()));

Еще один момент, остерегайтесь добавления вызовов System.out, рассмотрите возможность использования инфраструктуры ведения журналов.

...