Looking into the legacy repo I can see that the fix for the StringBuffer issue was not brought into Geode. The fix was to specifically request the Oracle/Sun implementation. Since that implementation might not be available in the IBM JDK its probably not a great fix.
On Fri, Aug 18, 2017 at 9:28 PM Darren Foong <darrenfo...@gmail.com> wrote: > > You're right. This did come up with the IBM JDK and we fixed it. Not > sure why then it's coming up again. > > Could it be this? https://issues.apache.org/jira/browse/GEODE-135 > Seems like a different issue with the IBM JDK though. > > I've just verified that the whitespace problem is still an issue with > the IBM JDK (because it uses Apache Xerces), and this pull request > fixes it. > > Not sure why the reporter for GEODE-135 didn't face a similar problem back > then. > > - Darren > > On Sat, Aug 19, 2017 at 6:04 AM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > > You're right. This did come up with the IBM JDK and we fixed it. Not > sure why then it's coming up again. > > > > Sent from my iPhone > > > > On Aug 18, 2017, at 2:01 PM, Dan Smith <dsm...@pivotal.io> wrote: > > > >>> Since the oracle parser is always going to be there I don't see any > harm > >> in doing that. > >> > >> That's not true if we're running on non-oracle JDKs, right? I remember a > >> while back someone was trying to run geode on IBMs JDK and having > issues - > >> maybe even this same whitespace problem? > >> > >> I think it this fixes issues with other parsers it looks good to me, I > >> don't have a problem with adding xerces as a test dependency. > >> > >> -Dan > >> > >>> On Fri, Aug 18, 2017 at 10:48 AM, Jacob Barrett <jbarr...@pivotal.io> > wrote: > >>> > >>> I could have sworn at one point the the cache xml parser explicitly > >>> requested the oracle parser. Since the oracle parser is always going > to be > >>> there I don't see any harm in doing that. > >>> > >>> A better fix might be to just normalize the white space when parsing. > >>> > >>> I also recall xerces having a flag for controlling the white space > >>> treatment. > >>> > >>> -Jake > >>> > >>> > >>> Sent from my iPhone > >>> > >>>> On Aug 18, 2017, at 10:25 AM, Anilkumar Gingade <aging...@pivotal.io> > >>> wrote: > >>>> > >>>> Why worry is claiming to support multiple version; and trying to > >>>> manage/maintain it... > >>>> > >>>> -Anil. > >>>> > >>>> > >>>> On Thu, Aug 17, 2017 at 11:35 PM, Darren Foong <darrenfo...@gmail.com > > > >>>> wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> I'm using Geode in an application that uses the Apache implementation > >>>>> of Xerces. The Oracle JDK comes with its own implementation of > Xerces. > >>>>> > >>>>> I encountered an issue > >>>>> (https://issues.apache.org/jira/browse/GEODE-3306) whereby cache.xml > >>>>> parsing fails with Apache Xerces; details are in JIRA. > >>>>> > >>>>> Currently there are two workarounds: > >>>>> > >>>>> 1. Remove the whitespace between elements in cache.xml > >>>>> 2. Load the JDK Xerces when parsing cache.xml > >>>>> > >>>>> I've submitted a pull request > >>>>> (https://github.com/apache/geode/pull/668) to make `CacheXmlParser` > >>>>> compatible with both versions of Xerces. > >>>>> > >>>>> This change would be useful for at least two groups of people: > >>>>> > >>>>> 1. Developers who are using the Apache implementation of Xerces > >>>>> throughout their application, and only want one implementation of > >>>>> Xerces > >>>>> 2. Developers who are using a non-Oracle JDK > >>>>> > >>>>> Does anyone have any objections to having `xercesImpl` as a test > >>>>> runtime dependency? > >>>>> > >>>>> I'd appreciate any feedback. Thank you! > >>>>> > >>>>> Best regards, > >>>>> - Darren Foong > >>>>> > >>> >
