[jira] [Resolved] (JOHNZON-194) Issue 190 -> Issues when call close method more than twice using Queue as buffer strategy.

["Romain Manni-Bucau (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JOHNZON-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Manni-Bucau resolved JOHNZON-194.
----------------------------------------
       Resolution: Fixed
         Assignee: Romain Manni-Bucau
    Fix Version/s: 1.1.11

Fixed in JsonParser

Side note: I'm not convinced a Buffer class would help. These close methods are not intended to be called multiple times. If done it is a bug in the caller code and even if the buffers are protected against that it can have side effects anyway so probably better to stick with current approach IMHO.

> Issue 190 -> Issues when call close method more than twice using Queue as buffer strategy.
> ------------------------------------------------------------------------------------------
>
>                 Key: JOHNZON-194
>                 URL: https://issues.apache.org/jira/browse/JOHNZON-194
>             Project: Johnzon
>          Issue Type: Improvement
>            Reporter: Steve Hubert
>            Assignee: Romain Manni-Bucau
>            Priority: Major
>             Fix For: 1.1.11
>
>
> Hello,
> Issue 190 is not completely solved.
> The writer has been fixed but not the parser.
> Note that I didn't check if there are some other places where a user may corrupt a BufferProvider.
> The issue is also reproducible via the maintenance_1.0x branch.
> Now a jonhzon buffer is just a char[] or a StringBuffer.
> It has neither state (open/close) nor methods to hide the BufferProvider logic.
> A way to protect johnzon  against this bugs family is to add a Buffer.java class.
> This new Buffer.java could be responsible to store the state and encapsulate the BufferProvider stuff.
> Bonus point this class may also contain some methods to write into the buffer and to fill it from an external source.
> As of today these methods are spread into the parser and the writer.
> I understand this refactoring is a lot of work and it may not be worth the effort.
>  
> The code below shows the issue.
> {code:java}
> public class App {
>     public static void parse(final JsonParser parser) {
>         Event e;
>         do {
>             e = parser.next();
>             switch (e) {
>             case KEY_NAME:
>                 System.out.println("KEY_NAME: " + parser.getString());
>                 break;
>             case VALUE_STRING:
>                 System.out.println("VALUE_STRING: " + parser.getString());
>                 break;
>             default:
>                 break;
>             }
>         } while (parser.hasNext());
>     }
>     public static void main(final String[] args) throws Exception {
>         final String jsonText1 = "{\"name\":\"App_1\", \"value\":\"value_1\"}";
>         final String jsonText2 = "{\"name\":\"App_2\", \"value\":\"value_2\"}";
>         final JsonParser jsonParser = Json.createParser(new ByteArrayInputStream(jsonText1.getBytes()));
>         jsonParser.close();
>         jsonParser.close();
>         final JsonParser jsonParser1 = Json.createParser(new ByteArrayInputStream(jsonText1.getBytes()));
>         jsonParser1.next();   // write jsonParser1 buffer
>         final JsonParser jsonParser2 = Json.createParser(new ByteArrayInputStream(jsonText2.getBytes()));
>         jsonParser2.next();   // overwrite jsonParser1 buffer
>         System.out.println("\nParse: " + jsonText1);
>         parse(jsonParser1);
>         System.out.println("\nParse: " + jsonText2);
>         parse(jsonParser2);
>         jsonParser1.close();
>         jsonParser2.close();
>     }
> }
>  {code}
> Output:
> {code:java}
> Parse: {"name":"App_1", "value":"value_1"}
> KEY_NAME: name
> VALUE_STRING: App_2
> KEY_NAME: value
> VALUE_STRING: value_2
> Parse: {"name":"App_2", "value":"value_2"}
> KEY_NAME: name
> VALUE_STRING: App_2
> KEY_NAME: value
> VALUE_STRING: value_2
> {code}
> Best regards



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)