In case this didn't get through gmail...

Begin forwarded message:

From: Jim Marino <[EMAIL PROTECTED]>
Date: April 7, 2006 10:02:21 AM PDT
To: tuscany-dev@ws.apache.org
Subject: Re: Does SDO 2.0 have logging capability such as JSR47?


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





Reply via email to