I agree we need to add more logging (but not too much imo, e.g.
exceptions should only be logged at container breaches and not as
they are propagated up the various Tuscany layers) and examples.
The monitor factory will be configured as a system service, as
opposed to currently being instantiated directly in Tuscany code, and
we are in the process of making those changes. This will allow the
MonitorFactory to be autowired into Contexts, which can then pass
specific monitors to Tuscany class instances via their constructor.
I don't think application code should use any of the monitor
facilities, but should instead use a logging package chosen by the
developer. Extensions to the runtime (components) should use the
monitor factory and they will be able to get a reference to it
through autowire, which they can use to create monitors and pass to
instances they instantiate. This can be done by adding an annotation
to a field or setter on the system component (an example is in
o.a.t.c.system.context.SystemCompositeContextImpl) .
Perhaps we should get these changes finalized ASAP and start
refactoring the code to make more use of logging? As we do this, we
can document it as part of the extensibility model.
Jim
On Apr 7, 2006, at 3:51 AM, rick rineholt wrote:
Recently looked at the logging code too and the only
example I caught with its
usage was a unit testcase. But this has mock
artifacts that is not a good
example to point to learn from. I have roughly the
same questions that Sebastien
wrote.
This question has come up a few times before
(http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
msg01440.html)
and I'd like to have for the website developers's
getting started either a
pointer to some code or a snippet that shows the best
practices for
logging/trace in Tuscany.
Thanks.
Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
After the issues last night with Tomcat, I feel
like trout-slapping
anyone who even mentions clogging.
Just needed to get that off my chest - sorry for
the noise.
--
Jeremy
Jim Marino wrote:
In the SCA Java runtime, we've implemented a
logging approach where a
class that needs to perform logging requests a
"monitor" that
implements a particular interface. This interface
has methods for
logging that are strongly typed, i.e.
"serverStartError(InitException
e)". The runtime is responsible for injecting
either injecting a
concrete monitor instance or factory for creating
them into the
requesting component. The concrete instance can
choose which logging
framework to use. The runtime can be reconfigured
to use a different
logging mechanism by changing the logging factory.
This avoids many of the logging problems
associated with things such as
commons logging (please don't use that one :-) )
Jim
As part of the changes to the assembly model that
I'm working on, I
would like to trace what's going in the model when
it's initializing for
example, but I'm not sure how to do it. How can I
get a monitor factory
or monitor instance? and how should I use it? Could
somebody in the
group start adding some real usage of the logging
framework to the core
runtime classes to show how to use it? Thanks.
On Apr 5, 2006, at 7:50 AM, Fuhwei Lwo wrote:
I couldn't find anywhere in the SDO 2.0
specification mentioning
about the logging capability for error or trace.
This is probably
SDO implementation details but I think it's
important to have some
kind of logging capability in SDO 2.0
implementation.
Any comments?
Fuhwei
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
