We are using Tuscany integrated with spring to provide aspects for logging and exception management. I agree that AOP is the ideal approach for these kinds of pieces of functionality. IMHO I would rather see Tuscany leverage Spring AOP then start developing its own aspect functionality from scratch regards Jeff
________________________________ From: Raymond Feng [mailto:[EMAIL PROTECTED] Sent: Tue 2007-08-14 12:23 To: [email protected] Subject: Re: Monitoring, logging and exceptions (again) Hi, I think we have three categories in this area: 1) Monitoring: Listen on the events generated by Tuscany, for example, a component is started or stopped. (Target for management interfaces) 2) Logging: Produce end-user readable information (info/warning/error) which is subject to I18N/L10N. (Target for end-users) 3) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) IMO, we can cover 2) & 3) using AOP. AOP-based tracing is obvious. It's simple to define pointcuts to trap all the methods of interest and dump out the input/output/exception data. @Pointcut("call(* org.apache.tuscany.sca..*(..))") Logging is a bit tricky because we will need to know what method calls are meant to be logging. We could use a Logger (for example, org.apache.tuscany.sca.logging.Logger or just the pure java.util.logging.Logger) in the code where logging is desired. Logger logger = ...; // By default, the logging is no-op logger.info(msgID, param...); // The code will be instrumented by an aspect if logging is desired Then we can create an aspect to trap the following pattern (any logging calls within the Tuscany code). @Pointcut("call(* org.apache.tuscany.sca.logging.Logger.*(..))") Thanks, Raymond ----- Original Message ----- From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "tuscany-user" <[email protected]> Sent: Friday, August 10, 2007 2:41 PM Subject: Re: Monitoring, logging and exceptions (again) > Simon Laws wrote: >> On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote: >> >>> On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote: >>> >>>> We talked about this before ( >>>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg16784.html) >>>> but >>>> didn't come to any conclusions. So, >>>> >>>> 1/ What is the requirement? >>>> 2/ What is the technical solution? >>>> 3/ When should we try and get it done? >>>> >>>> To get things going again here are some thoughts drawn from what was >>>> >>> said >>> >>>> in >>>> the referenced thread. >>>> >>>> 1/ An API in line with accepted logging/management practices to support >>>> arbitrary debugging and runtime info, warning and error logging >>>> A common approach to exception/error handling specifically around >>>> >>> the >>> >>>> detail recorded in the error messages >>>> Internationalization/localization >>>> Execution Tracing >>>> >>>> 2/ Keeping it simple was a popular sentiment >>>> A number of java logging solutions have been proposed Log4J, SLF4J >>>> etc. >>>> I believe DAS is using Log4J. >>>> We have dependencies that also use logging tools. We can take a >>>> look >>>> at how others approach this, e.g, quick glance at the last CxF release >>>> shows >>>> they include SLF4J jars >>>> Aspects were investigated to show how they can be used for tracing, >>>> seems like an interesting optional facility but adds extra >>>> complexity/dependencies >>>> There was also a suggestion that we could implement some higher >>>> >>> level >>> >>>> tracing, e.g. runtime starts, stops, application loading, component >>>> instance >>>> creation etc. >>>> We need to move error message out of the code and into resource >>>> >>> files >>> >>>> 3/ I think we can reasonably expect to agree what approach we are going >>>> >>> to >>> >>>> take fairly quickly and provide some examples, i.e. before the next >>>> release? >>>> People suggested before that we take time out to go through the >>>> code >>>> based and bring it into line. This will take a lot of time but can we >>>> >>> get >>> >>>> it >>>> into 1.0? >>>> >>>> Please add your thoughts to the list and we can then draw them >>>> together, >>>> try >>>> some of it out and come to some conclusions. >>>> >>>> Simon >>>> >>>> >>> +1 for going with SLF4J. If we can decide on this soon then we can all >>> just >>> start adding it in to the code we're working on and debugging, and then >>> maybe have a focused sweep before 1.0 to make sure its in everywhere >>> useful. >>> >>> ...ant >>> >>> >> >> Cross posting to the user list also as I expect this is close to everyone >> heart. Can everyone reply to both lists. >> >> Thanks >> >> Simon >> >> > > We had a similar discussion in April [1]. > > Here's what I suggest for logging: > > - Separate the trace calls from the runtime code. Insert them > automatically at build time or run time using Aspectj. Raymond on SCA and > Kelvin on SDO already showed how to do it. > > - Use SLF4J in these generated trace calls. > > [1] > http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL > PROTECTED] > > Thoughts? > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ----------------------------------------- ************************************************************************************** Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system. Thank you. Information confidentielle: Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre système. Merci. ****************************************************************
