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 >
