Hi,
Please see my comments below.
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, April 18, 2007 3:51 AM
Subject: Monitoring, logging, and exceptions (was: Re: Notifcation of
missing extensions)
On 4/17/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
<snip/>
I found our current Monitor stuff difficult to follow as well. I suggest
that we start a new discussion thread to discuss monitoring in general,
and try to come up with something that will be more usable and easier to
adopt through our whole runtime.
Starting the new thread for you...
I agree we should improve monitoring and logging in the runtime.
I've used AOP before for this type of thing, its cool, but it does add yet
another new thing to know about which could be off putting for new
developers. How about just using one of the existing logging packages that
most people are already completely familiar with? Commons Logging looks
like
its coming to its end, no one really likes java.util.logging, so how about
SLF4J, its really easy and nice to use?
I personally don't like the Commons Logging approach very much due to the
fact that conflicting versions are used by many 3rd party artifacts.
With regard to AOP, do we really need to have all the developers learn how
to use it? I assume we can put together some logging aspects in a separate
module to take care of most of the logging/monitoring concerns. Other
modules are not even aware of the existence of the AOP. Isn't it the
objective of AOP to address the cross-cutting concerns without poluting the
code?
I also think exception handling could be improved, I don't find the
current
exception formatter design easy to use, and most times stack traces end up
missing the important bit of information you need. How about just using
the
traditional way of putting everything in the exception message and using
properties files to allow for I18N?
I think we might be able to improve the ExceptionFormatter by providing a
default formatter which could dump out all the information in the exception
object. We already have a similar function in
"org.apache.tuscany.assembly.util.PrintUtil" and we could further enhance
it.
To support I18N, we could adopt a pattern for the exception so that a getter
or a field can be recoginzed as the message id.
One thing I've wondered about was having a release specifically targeting
these RAS type features. So once we've worked out the strategy for
logging,
exceptions, internationalization etc we have a release where a big focus
is
on implementing/fixing/testing all these RAS things.
+1. Enabling RAS is a big effort.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
