It sounds like these changes ought to be ok. If there is no objection, I will go ahead and pull them in this afternoon.
Thanks, Jared > On Aug 21, 2017, at 9:09 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > 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 >>>>>>> >>>>> >>
