Programmatically output model glue unity debug information

[Stephen Moretti]

I have a model glue application embedded inside a CMS.

The CMS is overriding the debug settings in my model glue application.

Is there anyway in say onRequestEnd() that I can pipe the debug info to a file?

Thanks in Advance

Stephen

[Jared Rypka-Hauer]

Hrm... dude I'd have to go back and look but I don't think that MG
actually exposes the debug output to the controllers.

That's an awesome ER tho... I'm thinking where if you have debug=true,
you could add logfile="path/to/log" and have it stuff all the debug
output in the logfile instead of on-screen.

I like it, actually... specifically for situations like this, or even
for application-level logging since it would then put trace statements
in the log file.

Anyone else have an opinion?

J

[Fernando Lopez]

This week we had a developer turn on Debug=true in CS and then deploy all the way to production without realizing of the change made.

Sure enough we started getting all sorts of emails and  calls because "the application went crazy". If we had a setting similar to init=true that one can pass to MG and then see the debug output only when required, then that would prevent mistakes like the ones we experienced this week.
I swore there was a setting similar to that (debug=true) somewhere in CF, was it another framework? or maybe CF itself? anybody knows?

In any case having it in MG would make a big difference.

Fernando

[Sean Coyne]

A while back I added an ER to add the ability to override the
LogRenderer in ColdSpring so you can use your own. Dan made the
change so it is usable now.

http://docs.model-glue.com/ticket/338

I'm not sure if you are referring to the CF debug info or the MG debug
info, but thought I would mention it.

Sean

On Oct 29, 11:52 am, Stephen Moretti <stephen.more...@gmail.com>
wrote:

[Stephen Moretti]

2009/10/30 Sean Coyne <coyne...@gmail.com>

A while back I added an ER to add the ability to override the
LogRenderer in ColdSpring so you can use your own.  Dan made the
change so it is usable now.

http://docs.model-glue.com/ticket/338

I'm not sure if you are referring to the CF debug info or the MG debug
info, but thought I would mention it

Sorry Sean. Yes I was looking for the ModelGlue debug output as opposed to the ColdFusion debug.

Jared, Yup that's perhaps a step on from what I was thinking about. I was just thinking something like :

somevar = ModelGlue.renderDebug();

and then I could push "somevar" out to a file of my choice or I could just output the renderDebug() in a view.

Thinking about it I suspect that the logfile="path/to/logfile" would be a bit restrictive in my particular instance and could result in a massive log file, but also sounds good to me for other uses. Might need a few additional attributes, like turn on/off execution times.

Stephen

[Sean Coyne]

Then that ER is what you may be looking for. Its for MG debug info
not the CF debug info.

On Oct 30, 11:17 am, Stephen Moretti <stephen.more...@gmail.com>
wrote:
> 2009/10/30 Sean Coyne <coyne.s...@gmail.com>

[Dennis Clark]

Stephen, are you using version 2 or version 3 of Model-Glue? I've been browsing the framework source for both and the debug logging code is quite different in the two versions.

Disclaimer: I have not actually tried any of the code snippets below. Getting them to actually work is left as an exercise for the reader :-)

To get the raw data for the current debug log from a controller method in Model-Glue 3:

logData = arguments.event.getTrace();

For Model-Glue 2:

logData = arguments.event.getEventRequest().getLog();

To get the rendered test for the current debug log from a controller method in Model-Glue 3:

logOutput = getModelGlue().renderContextLog(arguments.event);

For Model-Glue 2:

logRenderer = createObject("component", "ModelGlue.unity.debug.RequestLogRenderer").init();

logOutput = logRenderer.render(arguments.event.getEventRequest().getLog(), getModelGlue().getConfigSetting("debug"));

For both versions of Model-Glue, the debug log rendering occurs after all other request processing is complete, which means you cannot capture the complete debug output in either a view or a controller. If you must have the debug data for the entire request, your best bet in Model-Glue 3 is to provide a replacement logRenderer as Sean Coyne mentioned. If you're stuck in Model-Glue 2, your only choice is to hack the core framework code.

If you choose to create a replacement logRenderer to write to a file, I suggest you use a design pattern such as Decorator or Observer to maintain the original log rendering functionality.

Code that customizes built-in framework behaviors (such as log renderers) tend to be sensitive to changes in the framework. If possible, you should consider sharing any such code you write with the community so as to distribute the maintenance costs.

Cheers,

Dennis

[Jared Rypka-Hauer]

That's not actually quite the case.

You can easily override built-in classes, provided they're controlled by ColdSpring:

1) Go to /ModelGlue 3/ModelGlue/gesture/configuration/ModelGlueConfiguration.xml and find the block that defines modelglue.logWriter and modelglue.logRenderer:

<!-- 

Renderer that renders the ModelGlue Log.

-->

<bean id="modelglue.logRenderer" class="ModelGlue.gesture.eventrequest.log.LogRenderer" />

<!-- 

Writer that writes the that renders the ModelGlue Log.

-->

<bean id="modelglue.logWriter" class="ModelGlue.gesture.eventrequest.log.LogWriter" />

2) Go to your application's config/ColdSpring.xml and add bean tags with an ID of modelglue.logWriter and modelglue.logRenderer, but with class="" attributes that point to a location of your choice.

3) At the location of your choice from step 3, create 2 new classes, LogWriter and LogRenderer each of which extend the existing LogWriter and LogRenderer classes.

4) It's nice to start by copy/pasting the code from the 2 existing classes, then modify to suit your needs.

As far as I remember, the framework itself creates an instance of ColdSpring for the application, but that gets used as a parent bean factory another instance of ColdSpring created later in the loading process (I may be way off on that though). Failing that, the config files are all just merged and in that case the last one loaded wins. Either way, your new implementation of the logger and renderer will win and do as you told them to.

I used this technique to create a logging bean populator to see what was going on when I was having some issues with makeEventBean()... it works _s.l.i.c.k_...

J

PS - This power-user techinique is a major argument for CFC-based, configuration-based frameworks... MG in particular since it's backed up entirely by ColdSpring.

In /ModelGlue/config/ColdSpring.xml

[Dennis Clark]

On Thu, Nov 5, 2009 at 11:39 AM, Jared Rypka-Hauer <armcha...@gmail.com> wrote:

That's not actually quite the case.

You can easily override built-in classes, provided they're controlled by ColdSpring:

 

What specifically is not the case? I don't mind finding out I'm wrong as long as I'm shown where I went wrong. I don't see anything you said that really contradicts anything I said.

I only talked about the idea of replacing an internal framework component for customizing logging, but you actually showed us how to do it, so many thanks for that.

 

PS - This power-user techinique is a major argument for CFC-based, configuration-based frameworks... MG in particular since it's backed up entirely by ColdSpring.

Indeed. I've done it myself to customize some internal core CFC components in Model-Glue 2 and they work great. Unfortunately I got burned because those core components (which are not part of the public API) don't work the same way in Model-Glue 3 so I'd have to reimplement my customizations before my application will work on Model-Glue 3.

Cheers,

Dennis