cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <>
Subject Re: C2 with saxon
Date Tue, 25 Jun 2002 21:47:15 GMT
Vadim Gritsenko wrote:
> If you can, please create simple test case and send it to bugzilla.
I thought I did...done now.

Do you have some hints for tracking down bugs more effectively?
All the Components, Managers, Parent Managers and Manager Parents
and Children and Siblings and Selectors made me dizzy. It is like
stepping through a bytecode interpreter in order to debug the
interpreted program.

Just another example: After a small change (I thought), my project's
home page missed some content. I access an internal pipeline with
Here some commented log snippets:
- The URI passed to document is passed to XSLTProcessorImpl.resolve().
   DEBUG   (2002-06-25) 17:14.02:560   [core.xslt-processor] (/bredevc/index.html)
     resolve(href = cocoon:/int/news, base = file:/proj/...
- Actual resolving snipped
   DEBUG   (2002-06-25) 17:14.02:582   [core.manager] (/bredevc/index.html) ...
- Got a source (not a XSL source, but you knew this already)
   DEBUG   (2002-06-25) 17:14.02:698   [core.xslt-processor] (/bredevc/index.html)
     xslSource = ..., system id = cocoon://int/news
- Internal pipeline is called
   DEBUG   (2002-06-25) 17:14.02:700   [core.source-handler] (/bredevc/index.html)
     Resolving 'file:///proj/bre/team/interface/interface/news'
     in context 'file:/proj/bre/work/t384/webappdevc/build/webapps/bredevc/WEB-INF/'
   DEBUG   (2002-06-25) 17:14.02:703   [core.source-handler] (/bredevc/index.html)
     Resolved to 'file:/proj/bre/team/interface/interface/news'
   DEBUG   (2002-06-25) 17:14.02:707   [core.event-pipeline] (/bredevc/index.html)
      HttpProcessor[8080][1]/CachingEventPipeline: Recycling of CachingEventPipeline
   DEBUG   (2002-06-25) 17:14.02:709   [core.manager] (/bredevc/index.html)
      Put a org.apache.cocoon.generation.DirectoryGenerator back into the pool.
   DEBUG   (2002-06-25) 17:14.02:710   [core.manager] (/bredevc/index.html)
      Put a org.apache.cocoon.components.pipeline.CachingEventPipeline
       back into the pool.
   DEBUG   (2002-06-25) 17:14.02:712   [] (/bredevc/index.html)
      Recycling of CachingStreamPipeline
   DEBUG   (2002-06-25) 17:14.02:713   [core.manager] (/bredevc/index.html)
      Put a org.apache.cocoon.serialization.XMLSerializer back into the pool.
   DEBUG   (2002-06-25) 17:14.02:714   [core.manager] (/bredevc/index.html)
      Put a org.apache.cocoon.components.pipeline.CachingStreamPipeline
      back into the pool.
- Did something odd happen? All seems well, but then:
   WARN    (2002-06-25) 17:14.02:718   [core.xslt-processor] (/bredevc/index.html)
      HttpProcessor[8080][1]/TraxErrorHandler: Error in TraxTransformer:
       javax.xml.transform.TransformerException: Malformed URL [cocoon:/int/news]
    <snip repeated lines>
	at com.icl.saxon.StandardURIResolver.resolve(
	at com.icl.saxon.functions.Document.makeDoc(
Where the heck did Saxons default URI resolver pop up from?

In the beginning I saw only the exception and assumed something
went wrong again with setting up the resolver. It took me *hours*
to discover that the URI had been already resolved. The real reason
was that I introduced an action into the internal pipeline in order
to get some global configuration data, which returned null due to
some oversights. Saxon got a null Source and fell back to use it's
own default resolver, which of course cannot handle the cocoon:
protocol. A null source should never be delivered to a lower level
processing layer. (I'll report this tomorrow...)


To unsubscribe, e-mail:
For additional commands, email:

View raw message