>-----Original Message-----
>From: WHIRLYCOTT [mailto:[EMAIL PROTECTED]
>Sent: Donnerstag, 3. Juni 2004 21:34
>To: [EMAIL PROTECTED]
>Subject: question about debugging
>
>
>I'm new to Cocoon and I'm working on modifying an existing Cocoon
>application for a client. I'm finding that the process I'm
>using to add
>new features to the pre-existing codebase is error prone and I'm
>wondering if people can provide their thoughts on some of the
>following
>topics and possibly even share the approaches you use, how your dev
>environment is set up, etc.
>
>* At times, I want to simply peek at the value of a session attribute,
>request attribute, etc. at a certain point in a pipeline. If I was
>writing straight-up Java code, I could print out the value using log4j
>or something like this, look for the corresponding output in a
>log file
>and make some analysis. How do you go about doing this in your Cocoon
>sitemaps? Or do you do it differently altogether?
>
>* I seem to be consistently making incorrect assumptions about the
>scoping of request attributes, session attributes, etc. during the
>course of executing a particular pipeline. For example, I should be
>seeing a particular request attribute at a certain point in one of my
>pipelines, but it's apparently not there. I'm wondering if
>this has to
>do with a <map:act> block surrounding the code in question?
>Thoughts,
>links to docs for me to read, etc.?
Remember that <map:act> opens a new scope for map:match results,
ie. use {../1} instead of {1} inside the map:act body?
>
>I'm sure that some of you might be thinking that you need some code
>samples in order to tell me what's possibly wrong, but I'm looking for
>some more general wisdom of how _you_ are debugging problems in your
>pipelines, transformers, actions, etc.
I think you do have a misconception of how Cocoon pipelines work.
Each pipeline step may buffer events as it sees fit. So if you send
<a/>
<b/>
into a pipeline G | T1 | T2 | S where T1 changes a request attributes
when seeing event <b/>, there is no guarantee whatsoever what value
the attribute has at the time T2 receives <a/>.
>Right now, I'm relying on <map:serializer type="xml"/>
>statements being
>sprinkled throughout my code so that I can see what's happening by
>looking at a chunk of XML in my browser. I find that this approach is
>really inefficient and I'm looking for ways to improve it.
Have a look at using <map:view> and putting labels on pipeline steps.
That allows to peek at the XML output by just adding ?cocoon-view=label
request parameter without modifying the sitemap for debugging.
>
>I've also noticed that the vast majority of messages that get
>logged by
>Cocoon are DEBUG, even, for example, errors that are kicked back by my
>database server when a SQL INSERT statement fails. This also makes it
>trickier to cut down on the ~80Kb of log messages that are being
>generated per request in my dev setup.
DEBUG definitely produces too much output. We run dev usually in INFO,
prod on ERROR.
>
>I'd appreciate any thoughts on the topic of debugging in your
>development environments and any techniques that you use.
RequestGenerator for dumping context info as XML, aggregate with main
pipeline for debugging. Input modules {request-attr:name} can also be
handy.
If all else fails, run in Java debugger. Tomcat catalina.sh has the
hooks to do it embedded or remotely.
>phil.
>
HTH, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
