[kepler-users] logging actor

[Chris Weed]

I couldn't get Log4j to work, but the native logging works great.
I will probably make a hybrid of the two where the logging singleton is used
to aggregate log messages in a composite actor without connections, but
the displays are connected so you don't have multiple displays pop-up.
Chris

On Wed, Apr 29, 2009 at 10:56 AM, Ford, Mark <mark.ford at ll.mit.edu> wrote:
> 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
>