[kepler-users] logging actor

[Ford, Mark]

With the java logging approach, each actor would create its own Logger instance via Logger.getLogger("com.example.kepler.actor.MyActor"). The name passed to the static getLogger method should uniquely identify the logger. Convention dictates that the name matches the package structure but this isn't a requirement. The dot acts as a delimiter and allows you to create hierarchical namespaces for log statements. This value is typically defined statically within the class but it could be configurable (more on that in a bit). The single Java Logging actor I suggested below would interrogate the singleton LogManager class and ensure that it injected its Handler(s) into the appropriate chains to capture the logging. The LogManager can be inspected to find all of the registered Loggers (from previous getLogger) calls and it seems conceivable that a user could select which loggers will appear in the display or perhaps configure the threshold for logging (trace, debug, etc).

In your case, you might want to change the name of Logger based on whether the actor is nested within a composite actor. For example, if you might have two composite actors C1 and C2 and both contain an instance of actor A. Without any modifications, A would use "com.example.kepler.actors.A".  If you want to differentiate the logging output of C1's A versus C2's A then you could make this logger name (or a prefix) a param of the actor and set it accordingly on A.

With respect to propagating logging out of a composite actor with ports, I think you'd need to add an output port on the composite actor for logging and connect all of nested actors to this logging port. Either the composite actors never have a logging display or its configurable. This way you won't end up with multiple displays if your workflow contains multiple composite actors with this type of logging setup.

On 4/29/09 10:27 AM, "Chris Weed" <chrisweed at gmail.com> wrote:

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
>




--
Mark Ford
MIT Lincoln Laboratory
244 Wood Street
Lexington MA 02420
(781) 981-1843
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20090429/4ecf4984/attachment.html>