[kepler-users] logging actor

[Chris Weed]

It seems like the usual programming pattern for Java with Log4J is to put a
logging singleton in classes and not have an explicit output of
logging messages.
This would seem to naturally map to putting a logging singleton into actors,
and not have an explicit output port for logging messages. Your point about
having an output port, and allowing the user to connect to it or not to control
whether it is used is appealing. Alternatively, it seems like an actor could
always write to the log, but control this with a boolean parameter or through
how log messages are filtered.

I think the most important thing for my use of logging is a hierarchical system
that captures the hierarchical nature of composite actors. I want the logging
to filter up from the internal actors to the outer workflow.
Chris

On Wed, Apr 29, 2009 at 9:51 AM, Ford, Mark <mark.ford at ll.mit.edu> wrote:
> There’s a Logging actor which accepts StringToken inputs. This assumes that
> the actors you connect to it have ports which produce meaningful logging
> info. With this actor you’d wire whatever actors you wanted to log into the
> Logging actor and it would record their log statements to a file. The
> contents of this file could always be displayed in a window as suggested in
> another post.
>
> The drawback here is that the actors that connect to the logger are required
> to have a port that outputs meaningful logging. I don’t know if this is
> necessarily the case with existing actors. If you’re creating actors from
> scratch then you could design them with this additional port in mind.
>
> Your suggestion of capturing standard out is possible as well. You could
> simply place an actor on the canvas which T’d System.out to the existing
> printstream plus your own display. This has its drawbacks as well since you
> might end up with lots of junk in the display or inconsistent formats.
>
> Another option would be to use the standard Java logging or an equivalent
> (log4j or commons logging) within the actors. Again, this assumes that
> you’re writing your own actors. Each actor would produce info, debug,
> warning, error, or trace log statements using the standard API. The logging
> API’s allow you to configure the handler chains for logging dynamically so a
> special logging actor could inject itself into the chain and thereby capture
> the log records and format them accordingly to its own display.
>
> I like the idea of having a logging port on each actor but I’d like the
> output to be structured so the consumer of the log info would be able to
> make some decisions about handling it. This would also make the logging very
> explicit since you’d be able to see the connections in the workflow and know
> which actors were contributing to the log. This may have its own problems if
> you have large workflows since you may end up with links all over the place.
>
>
> On 4/28/09 4:26 PM, "Chris Weed" <chrisweed at gmail.com> wrote:
>
> Hi,
> I would like to use an actor that will capture all of the logging from
> various actors and output these to a display.
> For example, it could capture everything sent to "standard out", and
> pipe this to a display.
> Another option would be that it holds a logging singleton and all of
> the other actors will write log messages to this singleton.
>
> Has anyone done this before.
> Chris
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users
>
>
>
>
> --
> Mark Ford
> MIT Lincoln Laboratory
> 244 Wood Street
> Lexington MA 02420
> (781) 981-1843
>