Tuscany Monitoring, was: Does SDO 2.0 have logging capability such as JSR47?

[Jeremy Boynes <jb...@apache.org>]

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.
> 
> 

The choice of logging framework is done by the user when they create the
runtime. They do this by passing an implementation of MonitorFactory
into the constructor of TuscanyRuntime. The default is the Null
implementation on the basis that if they don't care enough about logging
to supply an implementation then they probably don't want logging.

Which framework to use will depend on the runtime environment. So in
Tomcat for example we should be integrating with the Tomcat logging
system so that any messages logged by the Tuscany implementation will go
into the Tomcat log.

When I was doing the Tomcat integration I thought it was still using
clogging and log4j and that we would need to provide an implementation
of MonitorFactory that bridged to that environment. However, with 5.5
they switched to clogging over JSR47 logging which should mean that our
JSR47 MonitorFactory should work. Something worth trying would be to
change TuscanyHost to create the runtime using the JSR47 factory and see
if monitor events get sent to the Tomcat logs.

Yes, it is really the person embedding Tuscany that decides which
implementation to use. The framework is intended to allow them to bridge
monitor events into the logging system the host they are embedding in
uses. The goal is to allow them to consolidate host events and Tuscant
events into one log stream rather than to have Tuscany log using a
separate infrastructure.

The J2SE-based samples (e.g. HelloWorld) could switch to using the JSR47
MonitorFactory with logging.properties configured to send a few events
to the console (e.g. INFO only). It would be worth adding comments in
the configuration that allowed a user to easy switch the logging level
to DEBUG so they could see how the server works.

The "shallow" web application samples (where we start the runtime in the
webapp) should probably log using the ServletContext's log() method as
that is the "official" J2EE mechanism for web applications to log
events. This would need a new MonitorFactory implementation and could be
something a little more adventurous to take on (I don't have time right
now).

The "deep" integrated web application samples should not have any
logging setup in them as the logging framework would be set up by the
Tomcat integration (as above).

Finally, all of this applies to logging from the Tuscany runtime itself
and not to user components. They can still log any way they choose
(clogging, jsr47, some custom framework).

I think a useful extension we could provide would be to support the
injection of a logger as a component property.  That would go a long way
to quell my desire to reach for a large trout every time I see clogging
as it avoids the discovery problems.

Something like:

  public class MyComponent {
    public Logger log;
  }

  <component name="MyComponent>
     <properties>
        <l:log>com.example.MyComponent</l:log>
  ...

which would result in the injection of a JSR47 Logger with the name
"com.example.MyComponent"

The runtime would control the configuration of the logging
infrastructure avoiding the problems with applications setting up
conflicting configurations and allowing us to ensure all the resources
are unloaded when the deployment unit is unloaded.

--
Jeremy

[help wanted] Re: Tuscany Monitoring

[Jeremy Boynes <jb...@apache.org>]

Jeremy Boynes wrote:
> 
> Which framework to use will depend on the runtime environment. So in
> Tomcat for example we should be integrating with the Tomcat logging
> system so that any messages logged by the Tuscany implementation will go
> into the Tomcat log.
> 
> When I was doing the Tomcat integration I thought it was still using
> clogging and log4j and that we would need to provide an implementation
> of MonitorFactory that bridged to that environment. However, with 5.5
> they switched to clogging over JSR47 logging which should mean that our
> JSR47 MonitorFactory should work. Something worth trying would be to
> change TuscanyHost to create the runtime using the JSR47 factory and see
> if monitor events get sent to the Tomcat logs.
> 

Let me take that back. I realized that Tomcat actually logs through
clogging it's just that the default implementation behind clogging
changed from log4j to JSR47.

That means our Tomcat integration should use a MonitorFactory that talks
to clogging so that it integrates with the way Tomcat logs. If the user
reconfigures Tomcat logging to use log4j or something else other than
the default JSR47, then our messages will be handled as well.

In other words, we need a MonitorFactory implementation that delegates
to clogging. That should be fairly simple to do based on the existing
JSR47 one if someone would like to help out.

--
Jeremy