Create Log Message Filter or Command

[mpwoodward]

(Moved from http://trac.mach-ii.com/machii/ticket/62)

I was thinking that sometimes it would be nice for debugging to have either a bundled filter or even a command (not sure on this one) that logs a message. It could also take a snapshot of the event data.

Filter example:

<filter name="log">
  <parameter name="level" value="info"/>
  <parameter name="message" value="I doing this"/>
  <parameter name="eventSnapshot" value="true"/>
</filter>

Command example:

<log message="I doing this" level="info" eventSnapshot="true"/>

Thoughts on this in general? If in agreement, filter or command? The command seems a bit more clean to me.

Changed 4 years ago by kurtwiersma

I could see how this might be useful as a filter. I like the filter option better because then you extend the Mach II filter and add your own stuff if needed it for your app.

comment:1 Changed 4 years ago by peterfarrell

Status changed from new to assigned
I agree about implementing it as a filter instead of a command. I never thought that people might want to extend how the filter works and that gives greater flexibility than adding a command. Is it agreed to add a filter to the core in MachII.filters?

Thoughts on any additional parameters / functionality?
Do you like MachII.filters.LogFilter? as the file name?
comment:1 Changed 4 years ago by peterfarrell

Another idea is just log a message and dump the event at the trace level automatically for you at the beginning of each event-handler and subroutine. Right now the MachIILogger is setup to watch for logging levels "all", but we could set that to debug by default. This actually may be another ticket to discuss.

comment:1 Changed 4 years ago by Joe Campbell

I usually use the CF8 line debugger now since I recently moved website hosts.

Is there something that this new filter would show that the CF8 debugger wouldn't?

comment:1 Changed 4 years ago by kurtwiersma

I think the simple parameters you have should be good to start with. It seems like it should be a pretty simple filter with the idea that people can extend it if they want it to do more.
I like MachII.filters.LogFilter? as the name.
comment:1 Changed 4 years ago by peterfarrell

Version changed from 1.6.0 to Uncategorized
Milestone Mach-II 1.6.0 beta deleted
Re-targeted to be potentially introduced in a future version.

comment:1 Changed 4 years ago by peterfarrell

Milestone set to Uncategorized
comment:1 Changed 4 years ago by peterfarrell

@joe, the command would stick a snapshot of the event into the new Mach-II logging architecture. There are many situations where you may not be able to use the debugger (production) and having the ability to have turn on event snapshots might help in certain situations.

comment:1 Changed 4 years ago by peterfarrell

Component changed from framework - core to framework - filters
Milestone Uncategorized deleted
comment:1 Changed 4 years ago by peterfarrell

Owner peterfarrell deleted
Status changed from assigned to new
comment:1 Changed 3 years ago by peterfarrell

Cc kurtwiersma, mattwoodward, brianfitzgerald added
Guys, is this something we want to bundle with Mach-II 1.8 "Simplicity". I'm thinking it might be nice to have the ability to log a message great a snapshot of the event data so it shows up in the MachII logger output at the bottom of the page or have it show up in the debugger logger getting built in the dashboard.

If we add it, I think it should be added as a filter (not a command). Thoughts?

comment:2 Changed 3 years ago by kurtwiersma

hours set to 0
estimatedhours set to 0
totalhours set to 0
billable set to 1
The only issue I see with generating a "snapshot" of the event arg data is that often I have view large view files that I put in an event arg called content. Sometimes I also have several objects with imbedded objects in as event args. What if we allowed the expression syntax to be used when you specified the log message so that the developer could choose what should appear in the log output?

<log message="I doing this with event name '${event.name}'" level="info" />
comment:3 Changed 3 years ago by peterfarrell

Yea that would be great regarding using the expression syntax for the log message so it can be somewhat dynamic.

The attribute to add data to an log message is called additionalInformation. Maybe we could do this:

<log message="I doing this with event name '${event.name}'" level="info" additionalInformation="${event.getArgs()}" />

OR

<log message="I doing this with event name '${event.name}'" level="info" additionalInformation="${event.jobProfile.getMemento()}" />

This would replace the original idea of having a boolean flag called snapshot.

With the new Dashboard stuff did you thing a log command is still useful?

comment:4 Changed 3 years ago by kurtwiersma

Since we have all the logging infrastructure I think this is a simple way to expose it in the config file. I am not sure how much I would use it but it does seem like a simple thing to provide.

comment:5 Changed 3 years ago by peterfarrell

Matt, what are you're thoughts on this?

comment:6 Changed 2 years ago by peterfarrell

Cc adrianscott, mikerogers added
Milestone set to Uncategorized
Matt / Team, any thoughts on this enhancement?