Bug and fix

[Jeff Barnes <jb...@epicedge.com>]

History
=====

I downloaded Cocoon 1.8.2 on Feb 6, 2001.  Today I tried to use the
command line tool as follows:
java org.apache.cocoon.Cocoon -p $COCOON_PROPS clean-page.xml
clean-out.html

The clean-page.xml was distributed with cocoon under samples/xsp.

I got a NullPointerException, so after verifying the mundane details of
proper setup and configuration, I took the plunge into the source code
(very creative, btw... Actor, Director, Manager.  What do you want to be
when you grow up, Stephano? just kidding)

Actions
======

Anyway, Cocoon.main calls an instantiated
EngineWrapper.handle(PrintWriter, File).  This delegates to
Engine.handle(HttpServletRequestImpl(File),
HttpServletResponseImpl(PrintWriter)) which is not a nice thing to do,
switching the order and all...

But even more problematic is the fact that the inner class
EngineWrapper.HttpServletResponseImpl returns an explicit null when its
getOutputStream() is called, which is a shame, because Engine.handle()
calls that very method via OutputStream realOut =
response.getOutputStream(), and then tries to write to it, which of
course causes an unchecked exception.

I made a fix!!!!  I edited both Cocoon.java and EngineWrapper.java to
take into account the fact that Engine.handle() is writing to an output
stream.  There's an ugly local class in
EngineWrapper.HttpServletResponseImpl and I added a polymorphed method
called EngineWrapper.handle(OutputStream, File).  I think that was all,
but just in case I messed with Engine (I don't think I did), I uploaded
all three to my geocities account.

Would somebody check 'em?  They build fine and run fine in my
environment.

http://www.geocities.com/jbarnesweb/Cocoon.java
http://www.geocities.com/jbarnesweb/EngineWrapper.java
http://www.geocities.com/jbarnesweb/Engine.java

Thanks.

Jeff

--
Jeff Barnes
Java Architect
EpicEdge
5601 6th Ave South Suite 600
Seattle, WA 98108-2521
206.674.0902 (direct)
206.674.0060 (main)
206.954.6173 (cell)