Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)

[ant elder <an...@gmail.com>]

On 4/17/07, Jean-Sebastien Delfino <js...@apache.org> 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 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?

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.

   ...ant

Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)

[ant elder <an...@gmail.com>]

I was referring to this mail [1] when I mentioned commons logging and SLF4J.
I don't know if its worth converting if you've already used LOG4J. SLF4J
does have some nice features though, particularly parameterized log
messages. You can read all about it at: http://www.slf4j.org.

   ...ant

On 4/18/07, Kevin Williams <kj...@gmail.com> wrote:
>
> Is SLF4J a better route than Log4j?  If so, I wonder if we should convert
> over the RDB DAS.
>
> On 4/18/07, ant elder <an...@gmail.com> wrote:
> >
> > On 4/17/07, Jean-Sebastien Delfino <js...@apache.org> 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 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?
> >
> > 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.
> >
> >    ...ant
> >
>

Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)

[Kevin Williams <kj...@gmail.com>]

Is SLF4J a better route than Log4j?  If so, I wonder if we should convert
over the RDB DAS.

On 4/18/07, ant elder <an...@gmail.com> wrote:
>
> On 4/17/07, Jean-Sebastien Delfino <js...@apache.org> 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 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?
>
> 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.
>
>    ...ant
>

Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)

[Simon Laws <si...@googlemail.com>]

Ant

Replies in line

On 4/18/07, ant elder <an...@gmail.com> wrote:
>
> On 4/17/07, Jean-Sebastien Delfino <js...@apache.org> 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?


Simple is good. I've not done much with Aspects but we could really do with
keeping down the complexity quotient I think. I'm keen that whatever
information we put out can be transported to whatever management solution is
used in the future so having a facade for accepting logged information
sounds good. We can start off with a simple console logger and migrate to
more complex distributed managment/logging solutions if required in the
future.

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 agree that I find the current exception messages lacking but I have to
admit to not having studied how they are implemented so I'll go take a look
and come back on this one.

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 I'm stringly in favour of this and would very much like to help out. Even
if it's not all of the community if a few of us can take a sweep through the
code and get the level of error reporting/logging up a notch then that's
going to improve our usability no end. People don't expect the software to
be perfect but if it fails and doesn't give any clues in lots of cases that
that gives a bad impression. This is particulalry the case when the failure
is down to user input. So we need to be really careful about loading the
assembly model and loading extensions to report any detected inconsistencies
in a easy to understand manner.

   ...ant
>

Simon

Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)

[Raymond Feng <en...@gmail.com>]

Hi,

Please see my comments below.

Thanks,
Raymond

----- Original Message ----- 
From: "ant elder" <an...@gmail.com>
To: <tu...@ws.apache.org>
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org