The point of view I was thinking of is that the driver should be put back
into the state it started with (from the no argument constructor) and that
it shouldn't hold onto things if it is going to be reused. This means that
it uses a minimum of memory while it is idle.
I would argue that because the structure was not created by the Driver and
it was set externally then it should not hold a reference to it. If you
want to hold onto the driver and let the output stream get garbage
collected then the caller of driver is able to controll that.

In your situation you are still able to set the output stream again. I
wouldn't think making that one call is too inconvenient unless there is
something I don't know about.

As for asking for an npe, that will hapen if you create a new driver with
the no argument constructor then call render.

As for the bug, I think this is due to the renderer not being reset (which
it is now in the current cvs).

On Mon, 17 Sep 2001 18:26:34 Art Welch wrote:
> Keiron,
> I wonder if NULLing _source, _stream, and _reader in Driver.reset() is
> such
> a good idea. For my own use with the PCLRenderer I take advantage of the
> stream staying open to concatenate multiple invocations into one output.
> I
> suppose that the desired things could be saved off before calling reset
> (since thankfully you do not call close() or anything) and then put them
> back after. But this seems like a bit of a nuisance. But maybe I am the
> only
> one that does this. I know that for most of the other renderers it is not
> currently possible to concatenate multiple invocations in FOP. Just a
> though.
> Art

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to