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
