faults, logging, testing - oh my

[du...@us.ibm.com]

Just a couple of comments on yesterday's irc chat about
testing and all of the output generated.

- Axis itself should _not_ print or log anything by default.
  The only time Axis should ever print anything, or preferably
  log it, is when some debug flag is on.
- Axis should instead let the "user of Axis" determine what
  and when something should be logged or printed to the screen.
  Axis has no way of ever knowing when something should be
  printed.  In some scenarios getting Faults might be "the norm"
  and an ever growing log file (or exceptions to the screen)
  would be unacceptable for those customers.
- Axis should provide APIs that the "user of Axis" can
  programmatically tweak and the "user of Axis" should
  have control over what is done externally.
- The "user of Axis" will vary.  On the client it will be the
  code calling the JAX-RPC APIs.  On the server it will be the
  servlet.  I consider "Axis" to be the AxisEngine object and
  the "user of Axis" to be the code that uses that object.
  Likewise, on the client its the Service object but the same
  concept applies.
- We (axis-dev'ers) can decide what/when the AxisServlet
  should print stuff or log stuff - that's an implementation
  choice as the developers of the "user of Axis" code - but the
  key is that the choice is in the servlet not in Axis.
- There should be three different levels or roles:
    - Axis
    - "User of Axis" code (ie. samples...)
    - Test harness
  Like I said earlier, Axis itself should not generate any output.
  The "user of Axis" code might/can/should generate any output it
  believes is necessary for its own users to know what's going on.
  That might include printing exceptions or any other output just
  as if it were run stand-alone.  For example, I would expect the
  stockquote sample to still generate its output (good or bad) to
  the screen.
  The test harness code should hide all output from its
  user.  The only thing a user of the test harness (ie. someone
  who just runs "ant go clean") should see if some progress-bar
  type of status - like "running stockquote test..." or
  something like that.  Something that let the user know what's
  going on but doesn't bombard them with output.  When something
  fails I would expect to see a failure message but _not_ the
  exceptions itself sent to the screen.  Perhaps just something
  like:  stockquote test failed.   When there are lots of tests
  that fail sending everything to the screen will be too much.
  There should be a log file or something that the user can then
  go to to see what went wrong with that one test.

  This is the way we work here and I think it works fairly well.

-Dug

Re: faults, logging, testing - oh my

[co...@covalent.net]

On Wed, 17 Jul 2002, Steve Loughran wrote:

> > Just a couple of comments on yesterday's irc chat about
> > testing and all of the output generated.
> >
> > - Axis itself should _not_ print or log anything by default.
> >   The only time Axis should ever print anything, or preferably
> >   log it, is when some debug flag is on.
> > - Axis should instead let the "user of Axis" determine what
> >   and when something should be logged or printed to the screen.
> 
> I agree with all this, but want to repeat the concern of others, that
> because we include a log4j.properties in axis.jar, we can make a mess of
> webapp logging configurations when axis is pulled in and re-used inside
> another webapp.
> 
> So we should really not have a log4j properties file in the JAR, and for all
> our test runs we need to add it to the classpath. We could put one into
> WEB-INF/classes for the axis webapp, making it visible for easy
> customisation.

+1 !

Note that commons-logging will deal with a missing log4j.properties
by defaulting to INFO ( like all other commons-logging and jdk1.4 log )
and stdout.

Axis should log exceptions and important messages - but 
by exceptions I mean things that brake axis ( can't find a parser ),
not faults or things that are thrown to the user anyway.

Not sure on the server-side - the server should have a way to 
know if an exception was thrown by one of the services ( even if
the client will get it too as FAULT ) - but problaby some configuration
should be used.

Costin

Re: faults, logging, testing - oh my

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: <du...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Wednesday, July 17, 2002 6:54 AM
Subject: faults, logging, testing - oh my


> Just a couple of comments on yesterday's irc chat about
> testing and all of the output generated.
>
> - Axis itself should _not_ print or log anything by default.
>   The only time Axis should ever print anything, or preferably
>   log it, is when some debug flag is on.
> - Axis should instead let the "user of Axis" determine what
>   and when something should be logged or printed to the screen.

I agree with all this, but want to repeat the concern of others, that
because we include a log4j.properties in axis.jar, we can make a mess of
webapp logging configurations when axis is pulled in and re-used inside
another webapp.

So we should really not have a log4j properties file in the JAR, and for all
our test runs we need to add it to the classpath. We could put one into
WEB-INF/classes for the axis webapp, making it visible for easy
customisation.

-steve