Instrumentation is a very small part of what constitutes an viable
production monitoring solution. Admittedly its the first step and
probably the easiest (when you know what you are doing in terms of AOP
or raw BCI). But to develop a APM solution that is scalable, extensible
and versatile you need to have years of experience understanding what it
means to measure and collect and how best to model and execute this.
Nothing about AOP can help here - which is very evident in the many
products/projects built on AOP that have failed - that includes 99% of
the home grown solutions that in addition use logging, jmx, and .....
Build a solution that works independent of any instrumentation approach
whether it be AOP and/or ASM/BCI. If your proposed API includes Tracing
and Logging then give up now. Please. It does not scale at runtime or
during offline analysis =>
http://williamlouth.wordpress.com/2010/03/02/does-transaction-tracing-scale-analysis/
AOP should only be a glue between the code to be monitored and the
monitoring runtime itself =>
http://williamlouth.wordpress.com/2010/03/07/three-degrees-of-separation-in-apm/
Of course I would beg to question why anyone would ever attempt to build
such solution when then is already one that is unlikely ever to be
matched ;-)
From: Rajaraman Santhanam <[email protected]>
To:<[email protected]>
Subject: Re: [aspectj-users] AspectJ conflicts
Message-ID:
<12ae5545435.-6643429704258397856.-3466900434767145...@zohocorp.com>
Content-Type: text/plain; charset="utf-8"
Thanks for the reply. I did go through that document and have a fair
understanding of how the aspects are loaded.
My major concern here is, when I introduce a aop.xml (along other aop.xml
present in the resource path) to the AspectJ load time weaver, what not should
I do to modify the behavior of AspectJ that is essential for the application.
I can come up with few:
1) Should not have aspects that should potentially exclude already defined
application includes
2) Should not exclude packages that are needed bu that application by
introducing explicit excludes in the aop.xml
Regards,
Rajaraman
-------------- next part --------------
An HTML attachment was scrubbed...
URL:<https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20100906/ed888dfe/attachment.htm>
------------------------------
Message: 2
Date: Mon, 06 Sep 2010 11:25:36 +0530
From: Rajaraman Santhanam<[email protected]>
To:<[email protected]>
Subject: Re: [aspectj-users] AspectJ or ASM
Message-ID:
<12ae59d2b4f.-3948295706337780040.4254520615782263...@zohocorp.com>
Content-Type: text/plain; charset="utf-8"
Hi,
Any more users out there to comment on my request?
Regards,
Rajaraman
---- On Thu, 02 Sep 2010 12:49:28 +0530 Rajaraman
Santhanam<[email protected]> wrote ----
Thanks for the reply.
Exactly as you mentioned, I would like to do the same, collect performance
metrics of the java code using AspectJ's load time weaving.
More than for our own monitoring needs, this is a new feature we are panning to
roll out as part of our Application Management offering to our customers&
prospects.
Any insight on this when compared with ASM doing the same stuff?
Regards,
Rajaraman
---- On Thu, 02 Sep 2010 12:19:49
+0530<[email protected]> wrote ----
Hi Rajaraman,
yes you are right, AspectJ ( and LTW Weaving) will be a good tool for Java
Monitoring. At work, i have developped some aspects, coupled with JMX or loging
in flat files, to follow methods durations, call counters, pools ( threads,
Apache common pool,JDBC, EJB ...) and more ...
Cordialement / Best regards
Jean-Louis Pasturel
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
