Spring AOP: Disadvantages when using it - Spring Features which use Spring AOP do not have this disadvantages? -

im working spring framework 3.0.5 , spring security 3.0.5 , ive got questions aspect orientated programming. @ moment im trying figure out disadvantages , advantages of aspect orientated programming. of course, know them in theory: can avoid redundant code, have make changes in aspect, not everywhere in code , on. still got questions:

the disadvantage found out:

i wrote sample application using aspects spring aop. configured aspect annotations (@pointcut, @before, @aspect , one). methods triggered aspect (which part of pointcut of course) of course part of different class , not annotated anything.

=> think 1 big disadvantage when watching methods of other class not clear trigger aspect. needed no annotations or else, mentioned in pointcut of aspect. (i hope understand mean). thats why think aop makes code less understandable!

a) there solution problem? (can maybe solved when put whole configuration in xml file? dont think so.)

b) problem still exist when use aspectj instead of spring aop?

springs features using spring aop: dont have disadvantage?

as spring aop part of many spring features (just declarative transaction management or (maybe) spring security(?)) took closer @ features. not able find disadvantage @ all.

c) lets take declarative transaction management example: managing transactions easy annotations (@transactional) , dont find disadvantage mentioned above. can see methods trigger specific behaviour. (all @transactional methods trigger transactional behaviour) maybe misunderstood , isnt aop used? if did not misunderstood this, why here possible see methods trigger aspects , why isnt possible see in example above? know this!

thank answering! :-)

edit: a) , b) answered (use ide marks methods), c) still missing :-)

for point b) if use eclipse spring ide , aspectj plugin, or sts, ide show aspects woven in.

---

for point b) if use aspectj , ide supports aspectj (eclipse aspectj plugin, or sts), see markers in souce-code aspect woven in.

an disadvantaged of compile time aspectj is, not able wove aspects in libraries. (without advanced techniques).

---

for point c) there 1 disadvantage of declarative aspects @transactional. -- can forget put annotation on method.

but if have example rule like: every public method in class annoteted @service (or if build own @transactionalservice), transactional, not need specifiy @transactional annotation on each method. -- in summary: declarative aspects reading (you not overlook them), , if code (lets say) "individual" (instead of term "not consistent") . if work in environment strong architecural rules (like every public method in @service class...), can write rules down in point cut definition, instead of using declarative aspects.