jena-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Seaborne (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JENA-6) Need a consistent policy on closing streasm for Jena readers
Date Fri, 10 Dec 2010 11:14:01 GMT

    [ 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.


Mime
View raw message