You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2010/12/10 12:12:00 UTC
[jira] Created: (JENA-6) Need a consistent policy on closing
streasm for Jena readers
Need a consistent policy on closing streasm for Jena readers
------------------------------------------------------------
Key: JENA-6
URL: https://issues.apache.org/jira/browse/JENA-6
Project: Jena
Issue Type: Bug
Reporter: Andy Seaborne
Assignee: Andy Seaborne
Priority: Minor
See also https://sourceforge.net/tracker/?func=detail&aid=3067790&group_id=40417&atid=430288
Jena readers do not provide any gaurantees as to the state of the stream in terms of byte position after parsing. RIOT, and some original readers, also close the stream, on the principle the stream is no longer usable.
But Java zip streams signal end of stream but can continue to be read by moving to the next zip file entry. Closing the stream after parsing is wrong in this case.
The original report noted a wrapper can be used that does not pass through the .close.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JENA-6) Need a consistent policy on closing
streasm for Jena readers
Posted by "Andy Seaborne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970131#action_12970131 ]
Andy Seaborne commented on JENA-6:
----------------------------------
For the RIOT cases, and plain N3 (=Turtle), the input stream is wrapped in
a reader (for bytes->chars) and tokenizer (chars->parser tokens) so it's
using a "hand-off" pattern because the stream is read one token ahead for
parsing and so it not reusable in normal cases, ZipInputStream being
different because reading each entry doesn't get a separate input stream.
> Need a consistent policy on closing streasm for Jena readers
> ------------------------------------------------------------
>
> Key: JENA-6
> URL: https://issues.apache.org/jira/browse/JENA-6
> Project: Jena
> Issue Type: Bug
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Minor
>
> See also https://sourceforge.net/tracker/?func=detail&aid=3067790&group_id=40417&atid=430288
> Jena readers do not provide any gaurantees as to the state of the stream in terms of byte position after parsing. RIOT, and some original readers, also close the stream, on the principle the stream is no longer usable.
> But Java zip streams signal end of stream but can continue to be read by moving to the next zip file entry. Closing the stream after parsing is wrong in this case.
> The original report noted a wrapper can be used that does not pass through the .close.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JENA-6) Need a consistent policy on closing
streams for Jena readers
Posted by "Andy Seaborne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JENA-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Seaborne updated JENA-6:
-----------------------------
Component/s: RIOT
Summary: Need a consistent policy on closing streams for Jena readers (was: Need a consistent policy on closing streasm for Jena readers)
> Need a consistent policy on closing streams for Jena readers
> ------------------------------------------------------------
>
> Key: JENA-6
> URL: https://issues.apache.org/jira/browse/JENA-6
> Project: Jena
> Issue Type: Bug
> Components: RIOT
> Reporter: Andy Seaborne
> Assignee: Andy Seaborne
> Priority: Minor
>
> See also https://sourceforge.net/tracker/?func=detail&aid=3067790&group_id=40417&atid=430288
> Jena readers do not provide any gaurantees as to the state of the stream in terms of byte position after parsing. RIOT, and some original readers, also close the stream, on the principle the stream is no longer usable.
> But Java zip streams signal end of stream but can continue to be read by moving to the next zip file entry. Closing the stream after parsing is wrong in this case.
> The original report noted a wrapper can be used that does not pass through the .close.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.