[
https://issues.apache.org/jira/browse/CODEC-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945097#comment-13945097
]
Steven Wurster commented on CODEC-183:
--------------------------------------
I wouldn't know where to provide a patch with tests. I do not have a copy of
the latest code; we're running against 1.6 and I doubt we'll migrate to a newer
version anytime soon. I worked around the problem with reflection so obviously
that is only valid for the version I am working with.
The easiest solution is to change the {{encode()}} and {{decode()}} functions
in {{BaseNCodec.java}} to be public or at least protected instead of
package-private (and of course update the descendants of {{BaseNCodec}} to
reflect the change). As it stands right now they can only be called from
within that package and that makes reuse by third-parties effectively
impossible. Additionally, all of the variables in both
{{BaseNCodecOutputStream}} and {{BaseNCodecInputStream}} are private and there
are no protected getters, and so that completely removes reuse by third parties.
If you want to solve the problem without changing the visibility of those
various pieces, then you could add a new function to {{BaseNCodecOutputStream}}
whose signature looks like this:
{code}public void close(boolean closeStream){code}
that contains the code currently within {{close()}} but only closes the
underlying stream (i.e. the variable {{out}}) when {{closeStream}} is true.
Then change the existing {{close()}} function to call this new function with
the parameter set to {{true}}.
I guess a similar change could be done to {{BaseNCodecInputStream}}, but that
seems to be handled differently with respect to {{close()}}, at least in the
version I have. Like I said, I'm a couple versions behind and a quick search
shows that the newer versions have a thread-based context that I know nothing
about.
> BaseNCodecOutputStream only supports writing EOF on close()
> -----------------------------------------------------------
>
> Key: CODEC-183
> URL: https://issues.apache.org/jira/browse/CODEC-183
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.6
> Environment: I'm running with version 1.6, but quick look shows it's
> present in 1.8.
> Reporter: Steven Wurster
>
> The only way to add the EOF marker when encoding or decoding with the
> BaseNCodecOutputStream is via the close() function. The flush() function
> does not perform this logic, and it is questionable whether or not it should.
> The problem is that I want to write to a Base64OutputStream in the middle of
> writing to another stream. That is, I will write some content to a stream,
> then wrap that stream with a Base64OutputStream to write some more (encoded)
> content, and then finish writing directly to the original stream (and so not
> encoded). Calling flush() on the Base64OutputStream will not write the EOF
> marker, which means bytes can be lost. I do not want to call close() on the
> Base64OutputStream as that will propagate to my original stream, which I need
> to leave open.
> Ideas for resolving this include the following:
> * Adding a separate function for writing the final (EOF) bytes without an
> explicit close (hacky solution).
> * Changing the visibility of various functions and members so that I can
> write my own descendant that provides the functionality I want. Note that
> the encode() and decode() functions on BaseNCodec used in the close() routine
> are package-private, and so I cannot call them within a descendant.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
