On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > 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/tuscany-dev@ws.apache.org/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?
There were several posts on that referenced thread less keen on using aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the simplicity of the more traditional approach of explicit logging calls in Tuscany. ...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED]
