Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

On 12/15/16, 6:38 AM, Daniel Fuchs wrote: On 14/12/16 00:42, Joe Wang wrote: Thanks Christoph! I updated the webrev for the classes you mentioned below, in a few cases, used NetBeans' source format feature -- not for all of the classes though (esp. the crazily

Re: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type

p.8udev/> JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ <http://cr.openjdk.java.net/%7Eclanger/webrevs/8169112_jdk.8udev/> Thanks & best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com] *Sent:* Mittwoch, 14. Dezember 2016 21:52 *To:* La

Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

Thanks Christoph! On 12/13/16, 11:53 PM, Langer, Christoph wrote: Thanks, Joe. Overall, this looks better. -Original Message- From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Mittwoch, 14. Dezember 2016 01:42 To: Langer, Christoph Cc: core-libs-dev@openjdk.java.net Subject: Re

Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type

Please create a patch for JDK 8 or work with Aleksej (Aleksej backported your previous patch), and ask for approval through the jdk8-dev alias. Best, Joe Best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com] *Sent:* Dienstag, 13. Dezember 2016 23:18 *To:* Langer, Christoph

Re: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance

ead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev: http://cr.openjdk.java.net/~aefimov/8146271/9/01 Best Regards, Aleksej On 14/12/16 03:35, Joe Wang wrote:

Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is

Hi Frank, Thanks for the diligent work! I think we've made a great improvement over the PrettyPrint (tremendous ;-) ) Could you look into extracting the XML literal strings in the test into plain files (similar to the other 'gold' files)? What I'm hoping to see is that they'd look easily pre

Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

ginal Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Joe Wang Sent: Montag, 12. Dezember 2016 20:14 To: core-libs-dev@openjdk.java.net Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 Hi, This was the cleanup portion of the change for JDK-81673

Re: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance

Hi Aleksej, You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) wh

Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type

Hi Christoph, For the test, yes, please add an unit test based on the test submitted, sanitize / remove any private information in the original test where necessary. Best regards, Joe On 12/13/16, 12:31 PM, Langer, Christoph wrote: Hi, this is the fix for the regression introduced with 81

RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340

Hi, This was the cleanup portion of the change for JDK-8167340. As Lance suggested, it was split from the original webrev. In addition to that cleanup, I've added coverage to the entire StAX packages. This cleanup will reduce 138 warnings. jbs: https://bugs.openjdk.java.net/browse/JDK-817055

Re: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories

Hi Frank, Looks good to me too. Thanks for adding tests. Best, Joe On 12/7/16, 9:35 AM, Lance Andersen wrote: Hi Frank, Looks fine Best Lance On Dec 6, 2016, at 10:15 PM, Frank Yuan > wrote: Hi all Would you like to review http://cr.openjdk.java.net/~fyuan

Re: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192

line limit shall be held which is not completely true in StreamReaderTest.java. But I know how difficult that is, while keeping the code still readable. Especially with the long speaking Class and method names ;-) Best regards Christoph -----Original Message- From: core-libs-dev [mailto

Re: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192

and to cover the stream package, but leave the impl package for a later time. Thanks, Joe On 11/30/16, 5:07 PM, Lance Andersen wrote: Hi Joe Looks OK. I might suggest a separate issue for the cleanup and just have this bug address the bug fix Best Lance On Nov 30, 2016, at 4

RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192

Hi, Please review an one-line fix and a bunch of cleanups. The reported issue was caused by a missed setting when the XMLStreamReader initializes the XML 1.1 scanner, so while the changeset involved 350 lines, the fix is really just the following: XMLStreamReaderImpl.java: @@ -605,11 +604,12

Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

ements and attributes (in SAX2DTM2.startElement()). I also removed some qname handling in DOM2SAX as it is not needed with my changes to SAX2DTM2 anymore. The test case was adopted. Thanks& best regards Christoph -Original Message----- From: Joe Wang [mailto:huizhe.w...@oracle.com]

Re: RFR JDK-8170192 [JAXP] [TESTBUG] test/javax/xml/jaxp/libs/jaxp/library/JAXPPolicyManager.java should grant permissions to jtreg, javatest, and testng jars

+1. Thanks Frank! -Joe On 11/23/16, 6:00 AM, Daniel Fuchs wrote: Hi Frank, Thanks for taking this on. Looks good to me. -- daniel On 23/11/16 04:41, Frank Yuan wrote: Hi All Would you like to review http://cr.openjdk.java.net/~fyuan/8170192/webrev.00/? Bug: https://bugs.openjdk.java.net

Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

be some special assertion around it? If it's ok for you, I'd push tomorrow. Thanks & Best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com] *Sent:* Samstag, 19. November 2016 00:23 *To:* Langer, Christoph *Cc:* core-libs-dev@openjdk.java.net *Subject:* Re: RFR:

Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

Hi Christoph, Once you're able to run all tests, feel free to push the changeset. Frank has fixed the Smoke test. Thanks, Joe On 11/18/16, 3:37 PM, Joe Wang wrote: Hi Christoph, Thanks for explaining the customer's dilemma with regard to their legacy process. The testcase I se

Re: Issues running JAXP jtreg tests ("java.lang.RuntimePermission" "accessDeclaredMembers")

Daniel, you're awesome! This could have potentially been a frustration to anyone with a newer testng, as Christoph and Volker have experienced. This issue really needs to be fixed immediately :-) Joe On 11/22/16, 7:58 AM, Daniel Fuchs wrote: On 22/11/16 14:51, Langer, Christoph wrote: In tha

Re: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource

test can be improved: Test all 4 source types Use a dataprovider (with data fields: Source, Transformer or NamespaceAware, Expected String, etc) Test also Templates to verify the namespace feature is propagated properly Thanks, Joe On 11/17/16, 9:14 PM, Joe Wang wrote: Together with

Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

de a transformation operation like the one that your SmokeTest does to TransformerTest which would illustrate the problem with namespace unaware SAX input data? Best regards Christoph -----Original Message- From: Joe Wang [mailto:huizhe.w...@oracle.com] Sent: Freitag, 18. November 2016 0

Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

ava.net/~clanger/webrevs/8169772.1/ <http://cr.openjdk.java.net/%7Eclanger/webrevs/8169772.1/> From my end this one is ready for pushing -- waiting for your final go. Best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com] *Sent:* Freitag,

Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

java.net/~clanger/webrevs/8169772.1/ <http://cr.openjdk.java.net/%7Eclanger/webrevs/8169772.1/> From my end this one is ready for pushing -- waiting for your final go. Best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com] *Sent:* Freitag, 18. November 2016 07:36 *To:* Langer,

Re: RFR: 8169772: [JAXP] XALAN: Transformation of DOM with null valued text node causes NPE

Looks fine. License header: in general, don't change / add Year if there's no material change, removing the legacy $Id field in EmptySerializer.java for example, does not constitute a change to the code, so just keep the original year (see below). The initial years for the classes:

Re: RFR: 8023653: xalan inconsistently parses DOMSource and StreamSource

Together with 8169631, I think we need to understand your customer's requirement before spending time on a change that would otherwise be unnecesary. Why would turning off namespace-aware help him? As far as the xml standards and parser/processor are concerned, it's a backward development. A na

Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

want to run the risk of adding a regression here just because I modified the code and did not well test it. But if you insist, I could have another look. Ok, that's fine. subList would do, but setSize may need a bit more work. Best, Joe Best regards Christoph -Original Message

Re: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

brevs with that regards. And I'll keep going to do formatting and warnings cleanups as I go... Thanks! That helps a lot. We had over 5000 warnings, hopefully we'd get rid of them all over a period of time. Best, Joe Best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@or

Re: RFR (JAXP) JDK-8169829 ProblemList update for javax/xml/jaxp/isolatedjdk/catalog/PropertiesTest.sh

+1. Again, if you find a solution for JDK-8169827, that would be good. But it's a low priority since we do have JCK in this area. Thanks, Joe On 11/17/16, 4:40 AM, Lance Andersen wrote: Hi Frank This is fine. For something this trivial, you can just include the diff in the email vs genera

Re: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

Thanks again, Daniel! -Joe On 11/17/16, 12:14 PM, Daniel Fuchs wrote: Looks good to me Joe. best regards, -- daniel On 17/11/16 19:58, Joe Wang wrote: Thanks Lance, Daniel, and Christoph. I adopted the changes as suggested. http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ The

Re: RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

with Daniel that you might want to reconsider reworking JdkXmlUtils.getValue to make it a bit more robust incase of an surprise Object passed for value. HTH Best Lance On Nov 16, 2016, at 5:12 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review an enhancement ad

RFR (JAXP) 8158619: Very large CDATA section in XML document causes OOME

Hi, Please review an enhancement adding a property to allow for specifying the chunk size of CDATA. JBS: https://bugs.openjdk.java.net/browse/JDK-8158619 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8158619/webrev/ Thanks, Joe

Re: [JAXP] RFR: 8169778: Add new public methods to get new instances of the JAXP factories builtin system-default implementations

On 11/16/16, 8:03 AM, Roger Riggs wrote: Hi Daniel, DocumentBuilderFactory and classes: - The new methods uses "Creates" instead of "Obtain"; perhaps it should be consistent with existing newInstance methods? "Obtain" was used in the early version of JAXP, and "Creates" in newer StA

Re: RFR: 8169631: [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yields a different result than namespace-unaware DOM input

Hi Christoph, Not all tests have finished yet, but there's at least one failure in the smoke test. I'll get to the details when I have time. Any reason why m_prefixMappings can not be replaced with ArrayList? Thanks, Joe On 11/14/16, 6:10 AM, Langer, Christoph wrote: Hi, please review this

RFR (JAXP) 8069098 : StAX produces the wrong event stream

Hi, Please review an update to the Javadoc of the StAX API from the JSR 173 specification [1], and fix to the implementation to comply with the specification that the reader's initial event shall be START_DOCUMENT. JBS: https://bugs.openjdk.java.net/browse/JDK-8069098 webrev: http://cr.openjd

Re: XMLReader secure processing

On 10/24/16, 10:40 AM, Bernd wrote: Hello, I am somewhat lost on how to enable or control the secure processing in the XMLReader. You can use XMLConstants.FEATURE_SECURE_PROCESSING and/or XMLConstants.ACCESS_EXTERNAL_{DTD,SCHEMA} only on the SAXParserFactory, but not XMLReader(Factory). Is t

Re: RFR (JAXP): 8167179: Make XSL generated namespace prefixes local to transformation process

Hi Aleksej, The change looks good. Thanks, Joe On 10/19/16, 7:19 AM, Aleks Efimov wrote: Hi, Please help to review the JDK9 fix for JDK-8167179 [1]: http://cr.openjdk.java.net/~aefimov/8167179/9/00/: The fix changes how the xsl:element namespace prefix values are generated during the tran

Re: RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: access denied ("java.io.FilePermission" "sko?ice")"

local encoding, that might be failed. After modification, the test should be passed on UTF-8 encoding, and the encoding which support the character '\u0159'. Thanks, Leo On 10/14/2016 06:49 AM, Joe Wang wrote: Hi Frank, Does this work as expected? The method doesn't seem to validate

Re: RFR (JAXP) JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: access denied ("java.io.FilePermission" "sko?ice")"

Hi Frank, Does this work as expected? The method doesn't seem to validate whether a character is legal as a file name. For example, on Windows, the original char (e.g. \u0159) used in the test is legal in a file name, but it didn't pass that decode/encode test by the Windows' default encoding

Re: RFR (JAXP) 8058152: JDK accepts XSLT stylesheet having import element erroneously placed

Thanks Naoto, Lance! I appended _ERR. -Joe On 10/12/16, 2:50 PM, Naoto Sato wrote: +1. You might want to append "_ERR" to the field "IMPORT_PRECEDE_OTHERS" to align with other errors (no need for further review). Naoto On 10/12/16 1:37 PM, Joe Wang wrote: Hi, Pleas

RFR (JAXP) 8058152: JDK accepts XSLT stylesheet having import element erroneously placed

Hi, Please review a change to validate that xsl:import element children /must precede/ all other element children of an element, including any element children as required by the specification [1]. [1] https://www.w3.org/TR/xslt#import JBS: https://bugs.openjdk.java.net/browse/JDK-8058152

Re: RFR (JAXP) 8152530: NullPointerException when xmlns=""

Thanks Daniel, Naoto! Changed to use prefix.isEmpty(). -Joe On 10/11/16, 1:41 PM, Naoto Sato wrote: Hi Joe, You could use prefix.isEmpty() to check if it's an empty string. Otherwise looks fine to me. Naoto On 10/11/16 1:29 PM, Joe Wang wrote: Hi, Please review a fix for a NPE whe

RFR (JAXP) 8152530: NullPointerException when xmlns=""

Hi, Please review a fix for a NPE when the source contains empty namespace. JBS: https://bugs.openjdk.java.net/browse/JDK-8152530 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152530/webrev/ Thanks, Joe

Re: RFR (JAXP) 8139584: XMLStreamWriterImpl does not write 'standalone' property

Thanks Lance! On 10/7/16, 10:07 AM, Lance Andersen wrote: Hi Joe, Looks fine Best Lance On Oct 7, 2016, at 12:10 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a fix for declaring the 'standalone' attribute. JBS: https://bugs.openjdk.java.net

RFR (JAXP) 8139584: XMLStreamWriterImpl does not write 'standalone' property

Hi, Please review a fix for declaring the 'standalone' attribute. JBS: https://bugs.openjdk.java.net/browse/JDK-8139584 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8139584/webrev/ Thanks, Joe

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

Nice to see fewer dependencies on internal API! As you have removed the exports, the related comment can go with it as well: // reflection access from com.sun.xml.internal.ws.api.streaming.XMLStreamWriterFactory -exports com.sun.xml.internal.stream.writers to java.xml.ws; Best, Joe O

Re: RFR: 8167002: JAXP schema validator: Use HashSet instead of ArrayList for tracking XML IDs

+1, great improvement! Best, Joe On 10/3/16, 7:28 AM, Daniel Fuchs wrote: Hi Martin, This looks good to me. best regards, -- daniel On 01/10/16 01:41, Martin Buchholz wrote: https://bugs.openjdk.java.net/browse/JDK-8167002 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/xml-id-validati

Re: RFR: 8164479: Update JAX-WS RI integration to latest version

On 9/23/16, 10:11 AM, Lance Andersen wrote: Hi Roman, I made a pass through the webrev and overall, looks OK. Would be good to have Joe Wang take a look at the Catalog changes as an additional sanity check. They look good to me. The dev note in Options.java, // use Sun's

Re: RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

-- daniel On 21/09/16 17:47, Joe Wang wrote: Hi Daniel, Here's the fix for the test issues, a couple of errors including missing handler in StAX test, and dtd was mistakingly typed as xsd . The root cause is a debugging assertEquals method that printed out debugging message without throwing

RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

net/~joehw/jdk9/8166398/webrev/ Thanks, Joe On 9/20/16, 11:22 AM, Joe Wang wrote: On 9/20/16, 2:20 AM, Daniel Fuchs wrote: Hi Joe, test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java 603 /** 604 * Returns the text of the first element found by the reader. 605

Re: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

Thanks Stefan for the update! I'm very glad to know you've gotten all of Ant's tests passed! Best regards, Joe On 9/20/16, 6:46 AM, Stefan Bodewig wrote: Hi Joe On 2016-09-08, Joe Wang wrote: It's great to know you've found the solution! Hopefully this is indeed th

Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

se jumped at me in your webrev :-) The incorrect javadoc was enough to raise an alarm, that this part of code was copied and forgot to update. It led me to double-check the code and found the issue (JDK-8166398). I really appreciate it! Best, Joe best regards, -- daniel On 19/09/16 20:11, Joe W

Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

Thanks Lance! Best Joe On 9/19/16, 1:13 PM, Lance Andersen wrote: Hi Joe, Seems OK. Best Lance On Sep 19, 2016, at 3:11 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review an addition of StAX tests to the Catalog Support test set. JBS: https://bugs.openjdk

RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

Hi, Please review an addition of StAX tests to the Catalog Support test set. JBS: https://bugs.openjdk.java.net/browse/JDK-8166220 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/ Thanks, Joe

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Thanks again, Daniel! Joe On 9/14/16, 12:25 PM, Daniel Fuchs wrote: On 14/09/16 20:09, Joe Wang wrote: Hi Daniel, Roger, Thanks for the review! The webrev is updated as we discussed. The deprecation message is in the main interface classes but stresses that the entire application under the

Re: RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

ese classes: then we could be confident that forRemoval=true is the better choice! best regards, -- daniel On 14/09/16 05:48, Joe Wang wrote: Hi, Please review the deprecation of the internal Catalog API. JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 webrev: http://cr.openjdk.java.net

RFR(JAXP): 8165784: Deprecate the internal Catalog API in JDK 9

Hi, Please review the deprecation of the internal Catalog API. JBS: https://bugs.openjdk.java.net/browse/JDK-8165784 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165784/webrev/ Thanks, Joe

Re: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded

I see. Thanks for explaining a "short" / 20-year history in a couple of sentences :-) -Joe On 9/12/16, 11:24 AM, Lance Andersen wrote: On Sep 12, 2016, at 2:20 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: On 9/12/16, 10:21 AM, Lance Andersen wrote: Hi Joe, On

Re: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded

On 9/12/16, 10:21 AM, Lance Andersen wrote: Hi Joe, On Sep 12, 2016, at 1:17 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi Lance, Since this change adds a test only, I assume the issue was fixed in another bug, it would be good to add a link in JBS. Yes I had planned t

Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore

Hi Frank, I was thinking we could just fix the current issue. Then in order to be consistent among different processors, we made wider changes. As you said, we're not backward-compatible anymore. That, and plus xml:space, it looks like a CCC can not be avoided. If that's what we have to do,

Re: RFR 8159126 Add test to validate DriverManager.println output when DriverManager is initially loaded

Hi Lance, Since this change adds a test only, I assume the issue was fixed in another bug, it would be good to add a link in JBS. It seems the initialization log has changed, no longer prints the first 2 lines. It might be worth it to add a note/comment in the JBS along with link to the orig

Re: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

know if this doesn't work. [1] https://bugs.openjdk.java.net/browse/JDK-8165116 Best, Joe On 9/1/16, 7:37 AM, Stefan Bodewig wrote: On 2016-08-31, Joe Wang wrote: On 8/30/16, 9:34 AM, Stefan Bodewig wrote: On 2016-08-29, Joe Wang wrote: If you are using the built-in extension func

Re: RFR JDK-8165617: Cleanup whitespace in jaxp/test

t Hi Frank, just out of interest: Is it a rule not to have any LFs at the end of java files? Best regards Christoph -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Frank Yuan Sent: Donnerstag, 8. September 2016 06:35 To: 'Joe Wang&#x

Re: RFR JDK-8165617: Cleanup whitespace in jaxp/test

Hi Frank, Looks good. Thanks for getting this cleaned up! Best, Joe On 9/7/16, 8:33 PM, Frank Yuan wrote: Hi This bug is to remove the extra LF from the end of the java files, that will help to conform with the normalizer. Anyone would like to take a look? http://cr.openjdk.java.net/~fyua

Deprecate JDK internal Catalog API in JDK 9

Hi, With the introduction of the new public Catalog API [1][2], we'd like to consider deprecating the old JDK internal API in package com.sun.org.apache.xml.internal.resolver and com.sun.org.apache.xerces.internal.util.XMLCatalogResolver. With JDK 9, this internal API is encapsulated (not ex

Re: RFR (JAXP): 8165116: redirect function is not allowed even with enableExtensionFunctions

Thanks Lance! Joe On 9/7/16, 10:49 AM, Lance Andersen wrote: Looks OK joe On Sep 7, 2016, at 1:32 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a fix for a missing check on the setting of property enableExtensionFunctions. Also closed the OutputStr

RFR (JAXP): 8165116: redirect function is not allowed even with enableExtensionFunctions

Hi, Please review a fix for a missing check on the setting of property enableExtensionFunctions. Also closed the OutputStream after transformation is done. JBS: https://bugs.openjdk.java.net/browse/JDK-8165116 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8165116/webrev/ Thanks, Joe

Re: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present

Thanks Daniel! -Joe On 9/1/16, 3:37 PM, Daniel Fuchs wrote: On 31/08/16 21:47, Joe Wang wrote: Thanks Aleksej! Hi Joe, Your last revision looks good. best, -- daniel -Joe On 8/31/16, 11:26 AM, Aleks Efimov wrote: Hi Joe, The changes looks nice (I'm not a reviewer) Best Re

Re: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message

Aleks Efimov wrote: On 31/08/16 23:55, Joe Wang wrote: On 8/31/16, 12:08 PM, Aleks Efimov wrote: Joe, (answers in-lined) On 31/08/16 21:39, Joe Wang wrote: On 8/31/16, 10:51 AM, Aleks Efimov wrote: Hi Joe, Thank you for reviewing the changes. I found one more inconsistency with these

Re: RFR: 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected.

Thanks Lance! Joe On 8/31/16, 1:14 PM, Lance Andersen wrote: Looks OK Joe Best Lance On Aug 29, 2016, at 3:18 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a patch that fixes an issue where circular references were not caught if catalogs are pre-loaded.

Re: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message

On 8/31/16, 12:08 PM, Aleks Efimov wrote: Joe, (answers in-lined) On 31/08/16 21:39, Joe Wang wrote: On 8/31/16, 10:51 AM, Aleks Efimov wrote: Hi Joe, Thank you for reviewing the changes. I found one more inconsistency with these tests: The TestSAXDriver class is not compiled by

Re: RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present

Thanks Aleksej! -Joe On 8/31/16, 11:26 AM, Aleks Efimov wrote: Hi Joe, The changes looks nice (I'm not a reviewer) Best Regards, Aleksej On 31/08/16 19:47, Joe Wang wrote: Hi, Please review a fix to the XSLTFunctionsTest. After enabling SecurityManager, the test now needs to se

Re: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message

k.java.net/jdk9/jdk9/jaxp/file/6aa83d55614a/test/javax/xml/jaxp/unittest/common/TransformationWarningsTest.java Thanks, Joe -Aleksej On 31/08/16 19:25, Joe Wang wrote: Hi Aleksej, It's good to put the tests back online. Thanks for the diligent work! I believe the change that made the

RFR (JAXP) 8161454: Fails to Load external Java method from inside of a XSL stylesheet if SecurityManager is present

Hi, Please review a fix to the XSLTFunctionsTest. After enabling SecurityManager, the test now needs to set the extension ClassLoader for the extension class. JBS: https://bugs.openjdk.java.net/browse/JDK-8161454 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8161454/webrev/ Thanks, Joe

Re: RFR: 8150145: javax/xml/jaxp/unittest/common/TransformationWarningsTest.java and ValidationWarningsTest.java failed intermittently without any error message

Hi Aleksej, It's good to put the tests back online. Thanks for the diligent work! I believe the change that made the tests run in othervm could have fixed the intermittent issue. But adding debugging code can always be helpful in case of failures. Thanks, Joe On 8/30/16, 12:01 PM, Aleks Efi

Re: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

Hi Stefan, On 8/30/16, 9:34 AM, Stefan Bodewig wrote: Hi Joe On 2016-08-29, Joe Wang wrote: If you are using the built-in extension functions, try turning on the following feature: private static final String ENABLE_EXTENSION_FUNCTIONS = "http://www.oracle.com/xml/jaxp/prope

Re: RFR (JAXB): 8159240: XSOM parser incorrectly processes type names with whitespaces

Hi Aleksej, The patch is fine. As we discussed, it's too bad the case [number]s were not universally unique in identifying the types (that makes it hard for the code maintenance), otherwise we would have been able to consolidate the collapse calls by types. We can live with the code as is, b

RFR: 8162431: CatalogUriResolver with circular/self referencing catalog file is not throwing CatalogException as expected.

Hi, Please review a patch that fixes an issue where circular references were not caught if catalogs are pre-loaded. Note that to trigger the issue (circular references), the Catalog must be instructed to load additional catalogs. This can be done by either setting DEFER to false, or providing

Re: Last Ant Test Failure with JDK9 - JAXP Secure Processing and XSLT Extensions

Hi Stefan, If you are using the built-in extension functions, try turning on the following feature: private static final String ENABLE_EXTENSION_FUNCTIONS = "http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions";; tf.setFeature(ENABLE_EXTENSION_FUNCTIONS, true); If you a

Re: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Thanks Lance! Best, Joe On 8/26/16, 12:41 PM, Lance Andersen wrote: +1 On Aug 26, 2016, at 1:06 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage sce

Re: RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Thanks Daniel! Best, Joe On 8/26/16, 12:01 PM, Daniel Fuchs wrote: Hi Joe, Looks good to me! -- daniel On 26/08/16 18:06, Joe Wang wrote: Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one

RFR: 8163232: CatalogResolver to extend XMLResolver and LSResourceResolver

Hi, Please review a consolidation of resolver support to CatalogResolver. The purpose is to simplify the interface and usage scenarios so that the one CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between sys

Re: RFR 8157797: SAX Parser throws incorrect error on invalid xml

Thanks Lance! Joe On 8/23/16, 12:34 PM, Lance Andersen wrote: Looks fine Joe. On Aug 23, 2016, at 12:53 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review a quick fix for an incorrect error that should never have been thrown. JBS: https://bugs.openjdk.java.n

RFR 8157797: SAX Parser throws incorrect error on invalid xml

Hi, Please review a quick fix for an incorrect error that should never have been thrown. JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/webrev/ Thanks, Joe

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

ails without the fix and passes with the new version of the fix. The JPRT and JCK testing again shows no related jaxp tests failures. Best Regards, Aleksej On 15/08/16 21:09, Joe Wang wrote: Hi Aleksej, I suggest we get rid of the static abort. If RuntimeException happens, check where it ha

RFR (JAXP) 6211561: XPath.evaluate(String, Object, QName) throws exception if context node is null

Hi, Please review a javadoc fix for XPath, and the same for XPathExpression. Error message is improved to be more relevant. Please ignore the Lic header for XPATHErrorResources.java, they will be handled in the future. JBS: https://bugs.openjdk.java.net/browse/JDK-6211561 Webrev: http://cr.

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

stigate. Thanks, Joe On 8/15/16, 11:09 AM, Joe Wang wrote: Hi Aleksej, I suggest we get rid of the static abort. If RuntimeException happens, check where it happens. The first use case looks suspicious as it just returns if it's an instance of RE. For the 2nd case in DOM error report,

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Hi Aleksej, I suggest we get rid of the static abort. If RuntimeException happens, check where it happens. The first use case looks suspicious as it just returns if it's an instance of RE. For the 2nd case in DOM error report, let's throw a RuntimeException with the specified error message if

RFR (JAXP) 8163535: javax/xml/jaxp/unittest/catalog/CatalogSupport2.java failed due to SocketTimeoutException

Hi, These tests shall accept any IOException. Please review. JBS: https://bugs.openjdk.java.net/browse/JDK-8163535 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8163535/webrev/ Thanks, Joe

Re: RFR (JAXP) JDK-8163468: javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermittently

+1, good to identify the cause. -Joe On 8/10/16, 4:17 AM, Daniel Fuchs wrote: Hi Frank, Good analysis of the failure root cause! The proposed fix looks good to me. As a side note, are there other multi-threaded tests in JAXP? If so maybe you'll need a special method in JAXPSecurityManager t

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

ed it but I didn't understand at that time :P Thanks Frank -Original Message- From: Frank Yuan [mailto:frank.y...@oracle.com] Sent: Thursday, August 04, 2016 6:06 PM To: 'Joe Wang'; 'Daniel Fuchs' Cc: 'core-libs-dev' Subject: RE: RFR (JAXP) JDK-8067

Re: RFR (JAXP) 8160069: RuntimeException thrown by XPathFactory::newInstance missing the cause

Thanks Lance! Joe On 8/4/16, 4:27 PM, Lance Andersen wrote: +1 Joe On Aug 4, 2016, at 6:06 PM, Joe Wang <mailto:huizhe.w...@oracle.com>> wrote: Hi, Please review the patch that sets the cause to the Exception: http://cr.openjdk.java.net/~joehw/jdk9/8160069/webre

RFR (JAXP) 8160069: RuntimeException thrown by XPathFactory::newInstance missing the cause

Hi, Please review the patch that sets the cause to the Exception: http://cr.openjdk.java.net/~joehw/jdk9/8160069/webrev/ Thanks, Joe

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

atest comments as well as had unittest/transform/TransformerTest.java up to date, please check http://cr.openjdk.java.net/~fyuan/8067170/webrev.03/ Thanks Frank -Original Message- From: Joe Wang [mailto:huizhe.w...@oracle.com] Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

anager and runWithoutSecurityManager in some of the tests? I thought the whole test suite will be run with and without security manager, isn't that the plan? Once again, great work and nice to clean up the old security-testing code. Best, Joe On 8/2/16, 2:56 PM, Joe Wang wrote: On 8/2/16, 5:30 A

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

On 8/2/16, 5:30 AM, Daniel Fuchs wrote: Hi Frank, I am intrigued by these change which do not seem to have anything to do with the rest. I mean, I'm not opposed as long as they are intended and that Joe validates them: http://cr.openjdk

Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Best, Joe Best regards Christoph *From:*Joe Wang [mailto:huizhe.w...@oracle.com] *Sent:* Freitag, 29. Juli 2016 22:34 *To:* Langer, Christoph *Cc:* Daniel Fuchs ; core-libs-dev@openjdk.java.net *Subject:* Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration whi

Re: RFR (JAXP): 8162598 XSLTC transformer swallows empty namespace declaration which is needed to undeclare default namespace

Hi Christoph, All tests passed. Please add a note to the test on what's expected, or some javadoc to the method checkNodeNS8162598. Best, Joe On 7/29/16, 7:55 AM, Langer, Christoph wrote: Hi Joe, here is the webrev after merging: http://cr.openjdk.java.net/~clanger/webrevs/8162598.2/

Re: RFR (JAXP) 8158084: Catalog API: JAXP XML Processor Support

Thanks Lance! Prabu believed that the JCK test should have been fixed by a previous patch. I'll send him a build to double-check. Best, Joe On 7/27/16, 1:17 PM, Lance Andersen wrote: Hi Joe, This looks OK to me. You might want to get the JCK test addressed before pushing your changes Best

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

On 7/27/16, 2:27 AM, Frank Yuan wrote: Hi Daniel Would you like to have a look at the following changes before I finish all rework? It shows runWithAllPerm, and the handling for user.dir property in FilePolicy.java. The code like runWithTmpPermission is still kept, please ignore them, I will

Re: JAXP: XSLTC transformer swallows empty namespace declaration which is necessary to undeclare default namespace

Hi Daniel, I tried your xsl, but I got the same result using either JDK 8 or a recent JDK 9 (jdk9dev) build: xmlns="ns2">xmlns="ns2"> For the issue with regard to empty namespace, please open a bug and let's fix it. Thanks, Joe On 7/26/16, 10:32 AM, Daniel Fuchs wrote: Hi Christoph, I

<    3   4   5   6   7   8   9   10   >