cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Cocoon running modes (was Re: Error Handling is NOT working)
Date Thu, 12 Sep 2002 12:34:55 GMT

Torsten

I've recently been working on the subject of exception management and 
logging in the context of the Merlin container.  Just like Cocoon, 
Merlin tends to spit out very log stack traces that make the process of 
end-user recognition of the real problem unnecessarily difficult.  I've 
recently put in place some changes to Merlin that solve this and I 
thought it may be helpful to provide an update on this.

Firstly, there is a problem concerning the reporting of exceptions under 
JDK 1.4 and later - the log file get filled with masive stack dumps 
where the causal exception get dumped in full and the causal exceptions 
causal exception get dumped in full, etc. etc.  This results in masssive 
duplication of exeception information.  

The solution I have in place is:

  (a) coding policy

      * when an error occurs, optionally log the message, NOT the 
exception,
        rethrow the exception (typically inside another cascading 
exeception)

      * this ensures that you get a ERROR or WARNING log entry in the log
        category under which the error/warning occurs, and the causal
        exception is propergated up the chain of control

  (b) considate error reporting somewhere high up in the application
      where it makes sence to dumpt the exception to the log file

  (c) generate a considated exception report

      * for all of the exceptions in the chain, generate a string buffer
        the contains the exception messages

      * dump the stack trace of last exception in the chain into the buffer

      * take the buffer result and enter it into the log

In the Merlin case - errors reporting now makes complete sence.

An example of the error log for an exception I'm throwing is include 
below just to demonstrate the final error reporting.  The actual 
exception message is prepared using the packException method in the 
org.apache.excalibur.merlin.ExceptionHelper class in the 
excalibur/assembly project (which can easily be copied/plundered for 
Cocoon requirements if it makes sence).

Cheers, Steve.


Code example:
-------------

    try
    {
        // do top level stuff
    {
    catch( Throwable e )
    {
        ExceptionHelper.packException( "kernel startup failure", e );
    }

Result:
-------

[ERROR  ] (root.kernel): Message: kernel startup failure
===================================================================
Exception: org.apache.excalibur.merlin.container.ContainerException: 
Unexpected error during container execution.
Cause: org.apache.excalibur.merlin.resource.LifecycleException: 
Component named "/root/complex" failed to pass through the 
initialization stage.
Cause: org.apache.avalon.framework.service.ServiceException: Service 
resolution failure for role: simple
Cause: org.apache.excalibur.merlin.resource.ResourceException: 
Unexpected exception while resolving the service from 
service:/root/simple#17984263 for the role: simple
Cause: org.apache.excalibur.merlin.resource.LifecycleException: 
Component named "/root/simple#17984263" failed to pass through the 
startup stage.
Cause: java.lang.RuntimeException: Steve's demo exception just for Cocoon
===================================================================
java.lang.RuntimeException: Steve's demo exception just for Cocoon
        at org.apache.excalibur.playground.SimpleComponent.start(Unknown 
Source)
        at 
org.apache.avalon.framework.container.ContainerUtil.start(ContainerUtil.java:251)
        at 
org.apache.excalibur.merlin.resource.LifecycleHelper.startup(Unknown Source)
        at 
org.apache.excalibur.merlin.resource.AbstractLifestyleHandler.createInstance(Unknown 
Source)
        at 
org.apache.excalibur.merlin.resource.SingletonLifestyleHandler.get(Unknown 
Source)
        at 
org.apache.excalibur.merlin.resource.DefaultResource.access(Unknown Source)
        at 
org.apache.excalibur.merlin.resource.DefaultManager.get(Unknown Source)
        at 
org.apache.excalibur.merlin.resource.DefaultServiceManager.lookup(Unknown 
Source)
        at 
org.apache.excalibur.playground.ComplexComponent.initialize(Unknown Source)
        at 
org.apache.avalon.framework.container.ContainerUtil.initialize(ContainerUtil.java:235)
        at 
org.apache.excalibur.merlin.resource.LifecycleHelper.startup(Unknown Source)
        at 
org.apache.excalibur.merlin.resource.AbstractLifestyleHandler.createInstance(Unknown 
Source)
        at 
org.apache.excalibur.merlin.resource.SingletonLifestyleHandler.get(Unknown 
Source)
        at 
org.apache.excalibur.merlin.resource.DefaultResource.access(Unknown Source)
        at 
org.apache.excalibur.merlin.assembly.ContainerManager.start(Unknown Source)
        at 
org.apache.excalibur.merlin.assembly.ContainerManager.start(Unknown Source)
        at 
org.apache.excalibur.merlin.container.DefaultContainer.start(Unknown Source)
        at 
org.apache.excalibur.merlin.container.ContainerResource.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:536)
===================================================================


tcurdt@dff.st wrote:

><snip/>
>
>  
>
>>Is this buffer size only related to development ? I don't think so. 
>>    
>>
>
>Well, of course not necessarily... but at least I wouldn't want this burden 
>that will definitly mean a drop of performance and worse scaleability for our 
>deployed system.
>
>The question is: for what type of user do we create those nice error messages?
>
>Actually from our clients I can tell - they don't have the slightest idea what 
>a specific exception could mean. And I bet same goes for most of the web users 
>out there. If there is an error they will call anyway and I have to look into 
>the logs. (Of course a nice page "Sorry, unavailable" is much nicer - but we 
>need to see what is the price to pay.
>
>But where it can definitly help to speed things up is at the development 
>stage... No more: "wait I need to turn this category on - do it again" or "wait 
>I need only 10.000 more lines to go through"
>
>But of course people may see this differently... ;)
>
>  
>
>>Error-handlers can also be used in production to handle 
>>exceptional-but-foreseen conditions (access denied, unavailable 
>>resource, etc). So the buffer size isn't only a matter of running mode.
>>    
>>
>
>Well, of course... but I would model such conditions within the sitemap and 
>don't use Exceptions ;) ...if they are foreseen...
>
>  
>
>>However, running mode is a great idea, which could be used for many more 
>>things than buffer size :
>>- central configuration for automatic reload of XSPs and sitemap in dev 
>>mode (and no reload in production mode),
>>- display the Cocoon "blue screen of death" to the browser in dev mode 
>>and a gentle "system currently unavailable" in production mode,
>>- other ideas ?
>>    
>>
>
>Hey, I didn't thought about all that... sounds cool:)
>
>- provide different logkit configurations?
>--
>Torsten
>
>-------------------------------------------------
>This mail sent through IMP: http://horde.org/imp/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message