And also my 2p inline...
...ant
On 8/16/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> 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.
I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a
facade for logging APIs, so you can code to the SLF4J API and then plug in
whatever logging impl you like, but if the only logging calls we have are
confined to a single tracing aspect we might as well just code that aspect
to a specific logging API like JDK logging. That avoids the extra dependency
on SLF4J and anyone can add additional aspects if they really want to use a
different logger. The main other benefit of SLF4J is its parameterized
message logging (avoids all the "if(logger.isDebugEnabled())" ) but again if
all the logging calls are in a single aspect thats not so useful.
What about mid-method logging of specific interesting events, for example
the contents of requests as the enter and leave bindings and implementation
types and things like that? That sort of logging is often all a lot of users
want to see not the detail tracing of every method entry/exit. Could we add
things like this in specific places?
<snip>
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.");
>
> }
Do we really need to internationalize the exception messages? That seems a
bit overkill to me, lots of (even commercial) software doesn't do that.
A little off topic, but do we need an InvalidContributionMetadataException
if the message is "Invalid contribution metadata for contribution"? It could
be just a generic exception with that message text. I don't really like the
way we have a zillion different exception classes, some of those
impl.javapackages have more exceptions than code making it real hard
to see the
actual code. It seems like its an attempt to avoid having to do
internationalization - "if it had a message it would need to be translated
so just make the class name the message text and then it wont have to be." -
but that doesn't actually make it any easier for non-english speakers.
Unless there's some reason someone would likely want to catch a specific
exception i think its better to just use a generic exception class with a
specific message.
> 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?
Can you remind me what the monitoring module did?
...ant
