fluo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [fluo] ctubbsii commented on a change in pull request #1077: Updated commons config from ver 1 to 2
Date Tue, 13 Aug 2019 16:39:19 GMT
ctubbsii commented on a change in pull request #1077: Updated commons config from ver 1 to
2
URL: https://github.com/apache/fluo/pull/1077#discussion_r313498057
 
 

 ##########
 File path: modules/api/src/main/java/org/apache/fluo/api/config/SimpleConfiguration.java
 ##########
 @@ -335,4 +334,35 @@ private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundE
     ByteArrayInputStream bais = new ByteArrayInputStream(data);
     load(bais);
   }
+
+  private String stream2String(InputStream in) {
+    try {
+      ByteArrayOutputStream result = new ByteArrayOutputStream();
+      byte[] buffer = new byte[4096];
+      int length;
+      while ((length = in.read(buffer)) != -1) {
+        result.write(buffer, 0, length);
+      }
+
+      return result.toString(StandardCharsets.UTF_8.name());
+    } catch (IOException e) {
+      throw new UncheckedIOException(e);
+    }
+  }
+
+  /*
+   * Commons config 1 was used previously to implement this class. Commons config 1 required
+   * escaping interpolation. This escaping is no longer required with commmons config 2.
If
+   * interpolation is escaped, then this API behaves differently. This function suppresses
escaped
+   * interpolation in order to maintain behavior for reading.
+   */
+  private Reader cleanUp(InputStream in) {
+    return new StringReader(stream2String(in).replace("\\${", "${"));
 
 Review comment:
   I think that's a reasonable approach... I'm just not sure how far you want to take it...
there may be other features of CC1 that changed in CC2 (or will change in future), and I'm
trying to understand if you want to try to set a precedent here, or if this is a one-off thing.
   
   Also, even if it's a one-off thing, is your intention to document the change in behavior
and drop it eventually, or maintain this backwards-compatible behavior indefinitely? I'm mostly
concerned about if/when this workaround becomes incompatible or difficult to maintain with
future versions of CC2 (or later), the more we expect specific behavior, rather than defer
to the underlying lib's feature set, the more we are responsible for increasingly complex
code. This isn't a problem now, but I'm wondering what your thoughts are for the future.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message