On 8/15/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> ant elder wrote:
> > 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]
> >
> >
>
> OK then, I don't care much about whether or not we use aspects, but I
> think that calls to trace method entry/exit+parameters should be
> externalized and inserted automatically when we build Tuscany, as IMO
> writing all these repetitive calls by hand will be problematic:
> - it's a lot of work and will be difficult to maintain and keep
> consistent (when methods are renamed, parameters added etc.)
> - it puts a big requirement on people contributing Tuscany extensions to
> write all these calls in their extensions as well
> - it will make Tuscany difficult to integrate in an environment using a
> different logging framework
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> A number of different requirements have been discussed and solutions
proposed. My 2p (I'm using Raymond's definitions b.t.w)
Tracing: Dump out input/output/exception for method calls for the purpose of
debugging/troubleshooting. (Target for developers/technical support)
I feel that tracing of execution paths through the Tuscany codebase would be
useful but agree that " it's a lot of work and will be difficult to maintain
and keep consistent" if we did it manually. I'm happy that this is the
responsibility of whoever wants to trace through the code and not a core
part of the codebase. For the Tuscany developer community AspectJ have been
proposed a couple of times and support has been prototyped. We could choose
SLF4J as the interface through which messages are output.
Monitoring: Listen on the events generated by Tuscany, for example, a
component is started or stopped.
We have had very little discussion about this. I expect this is because it
is generally accepted that from a management point of view it will be useful
to be able to tell which components are started, stopped etc. This will
likely be satisfied by Tuscany specific code at a fairly generic level, i.e.
it won't appear in many modules.
Logging: Produce end-user readable information (info/warning/error) which is
subject to I18N/L10N.
This seems to be one we have not really nailed down and it's probably the
most important one. In this category I include anything where we want to
write a message to a management console or log for a human user to read. In
most cases it is unlikely to be Tuscany's log but the log of whoever is
embedding the Tuscany code. I only differentiate this from the previous
category as we are expecting human readable messages to be produced. In
truth it might be the same interface. Let me provide concrete examples from
the current code.
>From CompositeWireBuider.wireComposite()
if (!promoted) {
warning("No targets for reference: " +
componentReference.getName(), composite);
}
>From ContributionServiceImpl. readContributionMetadata
} catch (XMLStreamException e) {
throw new InvalidContributionMetadataException("Invalid
contribution metadata for contribution.");
}
We need a consistent interface that allows us to record at least.
The SCA artefact to which the message relates, e.g. the uri of the
contribution, composite, component, reference, service etc
The message (or message identifier) we can take
internationalization/localization into account.
Any parameters associated with the message
Behind this interface is whatever, pluggable, platform mechanisms are
required to get this information to the right place. How about we bring a
monitoring module back to life?
Jeff also talked about " ...implementing service platform features which we
have mostly done using Spring aspects. These features include service
caching, service logging, service validation , and service error handling.
". It sounds like these are features distinct from how we handle events from
the Tuscany code itself. Is that correct?
Regards
Simon
