Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9CAEC200CEC for ; Mon, 21 Aug 2017 18:09:39 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 9B90116561B; Mon, 21 Aug 2017 16:09:39 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B983B165619 for ; Mon, 21 Aug 2017 18:09:38 +0200 (CEST) Received: (qmail 83244 invoked by uid 500); 21 Aug 2017 16:09:37 -0000 Mailing-List: contact dev-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list dev@geode.apache.org Received: (qmail 83232 invoked by uid 99); 21 Aug 2017 16:09:37 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Aug 2017 16:09:37 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0807D1806E2 for ; Mon, 21 Aug 2017 16:09:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=pivotal-io.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 85HW1YxB0p7J for ; Mon, 21 Aug 2017 16:09:34 +0000 (UTC) Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id E4B005F245 for ; Mon, 21 Aug 2017 16:09:33 +0000 (UTC) Received: by mail-qk0-f182.google.com with SMTP id z18so84888652qka.4 for ; Mon, 21 Aug 2017 09:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AWI89eUKpD9PJwfOfCNJ8XEOLYL16uGKY/HSj/7n9C8=; b=YEFDAOaU0dWiEzHqQfSEybtakcAGIM8NwtKi+eCiHxPWLWtNbsZpBCDKWsXed76iVd LYIDhcPKueAiGZPMFmQWgWjfeCC0cQ0U+qTqm0TGlBPKZ/1w3xdYQ5qy7PzOCIxXWbEl COEGOPewjIhDHANvhafGcWYhrsTQmyPKW0oz3Hx711aHs62JKSB0xN90UfatrTXz0wcR Vb+GijFzBWpqVSwnCFpXHaoJE2n+rvk4uPQ+bdXMJo3VNbfHOPIRCyrZ3aGPqEehyMSs yG9AqT9J8DPI4k0Jnk+YVgovLBpvpwvfnPi2RFFJdPp2FKrh9Yv8A/HMYYujEy9JE74v kfuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AWI89eUKpD9PJwfOfCNJ8XEOLYL16uGKY/HSj/7n9C8=; b=LR/hSf7b3ZusXEkiuzjI6tPC60jGmGepm5ecP1WmlBpXbWmxZ6XSmhpu7d5I4ryoZA MFDO7QzivGFBDYlmHbOwRH9Gp/O0+VfpgcLilA3+Ipl6uDzTzJq5kdSyv6MrJEs+nHqj WrohFvtSimlEv6ULfNJWfvtky0e9bBHd6HEXVC2dcj8lnN9vJJDxSrhv83jaUWRBL0so SXsNcQgarinHK3W7w5mVFtACBS9Kz4I6oWoEIBRjJleINa7RBx9n2gK7Vkae6xjGTdEy wxggFUgaSVK5tinmkjy7VZ0D4pCOEqBNwToyyOachY/CrZNkQcEzQUfy1zaCmorb66CP DT0g== X-Gm-Message-State: AHYfb5hztc9fsAVOTZutTrC/LytpCITPl0YxWCT5g+ManPaQxqEEjWnM Skc4x/b+4h2FGBvFwzmySeetaP9Hi/h0 X-Received: by 10.55.21.99 with SMTP id f96mr26735770qkh.173.1503331772610; Mon, 21 Aug 2017 09:09:32 -0700 (PDT) MIME-Version: 1.0 References: <704B6F0E-AEDA-4E8D-92F9-E363697FCBFD@pivotal.io> In-Reply-To: From: Jacob Barrett Date: Mon, 21 Aug 2017 16:09:21 +0000 Message-ID: Subject: Re: [Discuss] Compatibility with Apache Xerces To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="001a1147eba6496039055745b4bd" archived-at: Mon, 21 Aug 2017 16:09:39 -0000 --001a1147eba6496039055745b4bd Content-Type: text/plain; charset="UTF-8" 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 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 > 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 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 > 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 > >>> 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 > > >>>> 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 > >>>>> > >>> > --001a1147eba6496039055745b4bd--