Yes this should be possible by configuring the monitor system service
I mentioned in the previous email. I would imagine that most end
users would not configure this but it would rather be part of the
embedding process - i.e. on Tomcat we would have an out-of-the-box
configuration that dumps to clogging since Tomcat uses that. Of
course an end user could change this by modifying the system service
configuration if they wanted to.
Jim
On Apr 7, 2006, at 4:15 AM, rick rineholt wrote:
I also forgot to ask is just by taking a quick glance
through some code the
logging you get is largely determined by which monitor
factory is being used to
initialize the runtime with. It seems we have two
implementations of this
factory to offer NullMonitorFactory and
JavaLoggingMonitorFactory.
NullMonitorFactory just throws messages away if I read
it right.
JavaLoggingMonitorFactory uses standard Java provided
logging.
There doesn't seem to be a mechanism in place for the
enduser to decide which to
use. Currently from what I see this is hard coded in
most of the code to be
NullMonitorFactory.
So how do we plan on using this? Is this just for the
person embedding tuscany
to decide on? As we have done in the samples to use
NullMonitorFactory?
Is this what we want?
Even for the samples I'd like a way to turn on
logging.
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
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
