The general complaint with using AOP for logging is that it is not expressive enough. I think that the approach to overcome this is to call a Logger with the appropiate data and to have the aspect weave in the particular implementation into that Logger or none at all for minimal overhead. I beleive that the static and dynamic options for aspects provide enough options to satisfy most production environments though the most strick env will not allow dynamic, nor will want to deploy a rebuit jar with logging woven in.
In general I have no issues with externalizing the logging mechanism as this is basically the same thing but is configuration based rather than build based. Robbie On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Could you explain further? I may be totally missing things but here is my take as I understand it... I generally like AOP stuff but for logging I'm not sure it is good to use (despite the fact that AOP demos always seem to use logging as the example). It seems AOP techniques are better for doing things like tracing and analysis of runtime operation. In terms of logging, my issues are: 1. In most AOP systems I have come across, the pointcut language is not expressive enough to be able to select the proper joinpoints in code. For example, I may want to log in the middle of a method as opposed to entry and exit (more tracing functions) or at a synchronized block. 2. With AOP there are a couple of weaving options: static right after compilation and before deployment; runtime weaving by introducing custom classloaders and VM agents; through a VM api (only JRockit I believe supports this approach). I don't think we want to run the runtime through a static weaving process and the dynamic weaving generally will not work in heavily restricted environments. There are some custom AOP implementations that get around this but they are commercial (http://www.terracottatech.com/). 3. How do we handle internationalization? In our current approach, we use strongly typed exceptions. I don't think this can be done using AOP. Externalizing the logging process through a monitor factory seems to be the best solution I've come across for dealing with logging in libraries that are embedded. I've tried other approaches like "clogging" (Commons Logging) and have had significant headaches with version clashes and memory leaks. Jim On Aug 18, 2006, at 9:32 AM, Robbie Minshall wrote: > What do people think about providing various aspects to weave in log > statements for various frameworks. That way a user could weave in the > logging statements of their choice without a complicated > infrastructure. > > . . . thoughts ? > > Robbie > > > On 8/15/06, Jim Marino <[EMAIL PROTECTED]> wrote: >> >> I'm not sure you would want to use the entire thing as is since it >> makes use of the IoC engine. I would maybe look at the interfaces in >> org.apache.tuscany.spi.monitor and see if you can use those, >> providing your own mechanism for injecting a monitor into various >> classes. There was also a write-up n the Wiki as I recall that >> explains further. >> >> Jim >> >> >> >> >> On Aug 15, 2006, at 11:48 AM, Luciano Resende wrote: >> >> > Hi Jeremy >> > >> > What you guys did for SCA, is that something that could be used >> > across >> > other components on the project (e.g.: SDO/DAS) ? Or is something >> > specific >> > to SCA ? Could you point us where in the code to look for that ? >> > >> > - Luciano >> > >> > On 8/15/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >> >> >> >> It doesn't matter which logging framework you pick, it will be the >> >> wrong one :-) >> >> What I mean is that, as a library, you don't get to pick which >> >> logging framework the application that is using you chose. This >> >> provides a problem where log messages from the library may end up >> >> routed separately from the user's messages, or where the user >> needs >> >> to maintain multiple logging configurations. >> >> >> >> What we did in the SCA runtime is externalize logging. Any of our >> >> components can define a monitor interface that is independent of a >> >> logging framework. The runtime (not the user code) provides an >> >> implementation of that interface that forwards monitoring >> events to a >> >> logging framework that is provided by the user when they boot the >> >> runtime. >> >> >> >> There have been a few discussion on the list and I think on the >> wiki >> >> about our Monitoring Framework and MonitorFactory - it might be >> worth >> >> looking for those and see if they would work for DAS. >> >> >> >> -- >> >> Jeremy >> >> >> >> On Aug 15, 2006, at 9:26 AM, Darius Dejesus wrote: >> >> >> >> > I've been looking at some of the older JIRA's, and upon >> looking at >> >> > the way >> >> > logging was currently handled in the DAS, inconsistent at >> best, I >> >> > figured >> >> > now would be a good time to throw some questions out there. I >> >> > believe this >> >> > falls under Tucsany-292 and Tuscany-441. >> >> > >> >> > As it stands I'm wondering what logging framework would be >> best for >> >> > the >> >> > project. At this point I've been looking at the libraries >> contained >> >> > in both >> >> > org.apache.log4j and those found in java.util.logging. While I'm >> >> > aware that >> >> > log4j is more robust, I'm wondering if it's all needed for these >> >> > purposes. >> >> > Not having any prior experiences with either of these logging >> >> > libraries, I'm >> >> > not clear on any extra overhead or other possible issues they >> may >> >> > have. >> >> > >> >> > I'm also curious as to the overall goals of the logging >> system. I >> >> > imagine >> >> > this is more for the user then for us, so in that case all >> message, >> >> > exceptions and what not should probably be separated and >> organized >> >> > in some >> >> > standard way or place ( some logging/debugging directory >> perhaps ). >> >> > Also do >> >> > any of the other subprojects already have some form of >> logging in >> >> > place? >> >> > Should we all be using the same standards and files? >> >> > >> >> > Thats all I'm wondering about so far. I appreciate any feedback. >> >> > >> >> > -Darius DeJesus >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> > >> > >> > -- >> > ----------------------------------------------------- >> > Luciano Resende >> > SOA Opensource - Apache Tuscany >> > ----------------------------------------------------- >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > -- > * * * Charlie * * * > Check out some pics of little Charlie at > http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ > > * * * Addresss * * * > 1914 Overland Drive > Chapel Hill > NC 27517 > > * * * Number * * * > 919-225-1553 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- * * * Charlie * * * Check out some pics of little Charlie at http://www.flickr.com/photos/[EMAIL PROTECTED]/sets/ * * * Addresss * * * 1914 Overland Drive Chapel Hill NC 27517 * * * Number * * * 919-225-1553
