johnzon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Romain Manni-Bucau (JIRA)" <>
Subject [jira] [Commented] (JOHNZON-215) JsonReader.readObject() calls Reader.close()
Date Mon, 17 Jun 2019 14:10:00 GMT


Romain Manni-Bucau commented on JOHNZON-215:

[~joerg1985] Well, the RI is not the source of truth, the spec is. There are a lot of spec
where different implementations behave differently because it is not specified and it does
not prevent to write portable code.
We are exactly in that case here since both implementation are compliant to the spec so writing
portable code is fine. So "At development / testing time there might be another implementation
used as in production, this might lead to issues." assumption is not true here.
Implementing closeable also makes sense when you start decorating the API since it gives you
a hook which is useful even if the underlying stream is already closed. So the API is well
designed, the implementation respects it, it just makes it less error prone from the user
feedbacks we got.
Finally I would add that there is no reliable "lock" on the file, it is system dependent and
not something an user can rely on portably which is likely a biggest concern in your code
than the JsonReader itself IMHO.

In other words I tend to think your issue is not linked to johnzon on jsonp but another implementation
you rely on (windows file?). Is it accurate?

> JsonReader.readObject() calls Reader.close()
> --------------------------------------------
>                 Key: JOHNZON-215
>                 URL:
>             Project: Johnzon
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.12
>            Reporter: Jörg Sautter
>            Priority: Major
> We try to use the JsonReader to read a Reader based on a channel holding an exclusive
file lock and later on we truncate the channel, write the content and close the channel /
release the lock.
> As soon as we call JsonReader.readObject() the reader and the channel is closed and the
file locks are gone. This should - from our point of view - not happen at this point, only
a explicit call to .close() should close the underlying resources.
> This is a code snippet to reproduce the issue:
> {{StringReader sr = new StringReader("{}");}}
> {{Reader wrapper = new Reader() {}}
> {{@Override}}
> {{public int read(char[] cbuf, int off, int len) throws IOException{}}
> {{return, off, len);}}
> {{}}}
> {{@Override}}
> {{public void close() throws IOException{}}
> {{throw new UnsupportedOperationException("someone closed the stream!");}}
> {{}}}
> {{};}}
> {{Json.createReader(wrapper).readObject();}}

This message was sent by Atlassian JIRA

View raw message