Re: [16] RFR: 8251182: Fix "no comment" warnings in java.naming

Roger, Lance, Daniel, Thanks for your reviews. With Best Regards, Aleksei On 26/08/2020 16:59, Lance Andersen wrote: +1 On Aug 26, 2020, at 7:46 AM, Aleks Efimov <mailto:aleksej.efi...@oracle.com>> wrote: Hi Roger, Lance, Daniel, Thanks for your reviews and comments! N

Re: [16] RFR: 8251182: Fix "no comment" warnings in java.naming

annotation to serialVersionUID declarations. best regards, -- daniel On 25/08/2020 16:03, Aleks Efimov wrote: Hi, The documentation of classes from "java.naming" module needs to be improved to resolve javadoc -Xdoclint "no comment" warnings. JBS issue: https://bugs.openjdk

[16] RFR: 8251182: Fix "no comment" warnings in java.naming

Hi, The documentation of classes from "java.naming" module needs to be improved to resolve javadoc -Xdoclint "no comment" warnings. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8251182 Webrev: http://cr.openjdk.java.net/~aefimov/8251182/00/index.html CSR:

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, The last version looks good to me. Best, Aleksei On 14/08/2020 15:42, Alexey Bakhtin wrote: Sorry, That’s my bad. I have reverted @systemProperty to @code. The wording is fixed. Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v17/ Regards Alexey On 14 Aug 2020, at

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Sean, Alexey, Adding @systemProperty doesn't look correct here since the properties mentioned in the module-info.java are not system properties, they're standard JNDI environment properties and setting them via system property with the same name won't have any effect, e.g. "java

Re: RFR[testbug]: 8251189: com/sun/jndi/ldap/LdapDnsProviderTest.java failed due to timeout

8/2020 13:44, Aleks Efimov wrote: > Hi, > > LdapDnsProviderTest was seen failing due to the timeout caused by the > blocked bind operation. That could happen if there is a local process > listening on the port specified in the

RFR [testbug]: 8250772: Test com/sun/jndi/ldap/NamingExceptionMessageTest.java fails intermittently with javax.naming.ServiceUnavailableException

Hi, Please, help to review NamingExceptionMessageTest test stabilization change: There is a race condition between the closure of connection in test LDAP server and the JDKs LDAP client code. Due to this race the test could generate ServiceUnavailableException instead of the required

RFR[testbug]: 8251189: com/sun/jndi/ldap/LdapDnsProviderTest.java failed due to timeout

Hi, LdapDnsProviderTest was seen failing due to the timeout caused by the blocked bind operation. That could happen if there is a local process listening on the port specified in the test URL. To make LdapProviderTest.ProviderTest.call fail the LDAP connect timeout property needs to be set to

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

. Updated webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v14/ Regards Alexey On 10 Jul 2020, at 19:40, Aleks Efimov wrote: Hi Alexey, Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases. Please, find the comments about the latest

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, Thank you for removing the dependency on the timeout property and adding tests for TLS handshake cases. Please, find the comments about the latest webrev below: Not quite sure why the CF is completed at two places. Probably that’s OK, but it would be good to know the reason :)

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Sean, Alexey answered the same question for me: I mean “com.sun.jndi.ldap.connect.timeout” property. The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: Connection.java if (connectTimeout > 0) { int socketTimeout =

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

e explicit, perhaps by including "microsoft" or something like that in the property name. Thanks, Sean [1] https://tools.ietf.org/html/rfc5801 On 6/8/20 9:07 AM, Aleks Efimov wrote: Hi Alexey, I've looked through LdapCtx/LdapClient/SaslBind changes: Do we need to check if CHANNEL_BIN

Re: RFR [15/java.xml] 8237456: Transform filtered through SAX filter mishandles character entities

Hi Joe, The changes looks good to me. Best, Aleksei On 09/06/2020 06:54, Joe Wang wrote: Hi, Please review a fix to a regression that resulted in invalid output in a transform that contains entity references. The regression was caused by a JDK9 patch [1]. Adding back the conditional checks

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, I've looked through LdapCtx/LdapClient/SaslBind changes: Do we need to check if CHANNEL_BINDING is set explicitly for all connection types? Maybe we can move the check inside 'if (conn.sock instanceof SSLSocket) {' block. Also, instead of setting CHANNEL_BINDING in context

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, I have question about timeouts: LdapCtx has 2 timeout properties: connectTimeout and readTimeout. First one is for controlling the Socket::connect timeout (Connection::createSocket), another - for reading out the replies (Connection::readReply). Both of them have default values set

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, I agree with all Daniel's comments. Few thoughts about moving the implementation down to SASL layers: Will it be possible to make this new code specific only for JGSS/Kerberos authentication mechanism? Maybe investigate moving all the new code to GssKrb5Client SASL client

Re: RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout

be thrown if that happens. best regards, -- daniel On 07/05/2020 00:52, Aleks Efimov wrote: Hi, LdapDnsProviderTest test expects to have no services running on port on test machine. That could cause it to fail intermittently due to unexpected exception message thrown by LDAP client, i.e

RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout

Hi, LdapDnsProviderTest test expects to have no services running on port on test machine. That could cause it to fail intermittently due to unexpected exception message thrown by LDAP client, i.e. timeout or disconnect instead of expected connection refusal. The proposed fix tries to

Re: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure

Hi Daniel, Thanks for the review ! Best, Aleksei On 06/05/2020 11:35, Daniel Fuchs wrote: Hi Aleksei, Looks good to me. best regards, -- daniel On 05/05/2020 18:23, Aleks Efimov wrote: "LDAP response read timed out, timeout used:-1ms.": https://bugs.openjdk.java.net/browse/J

RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure

Hi, NamingException message is not precise about the cause of LDAP connection failure, i.e. in case of LDAP connection closure the NamingException with misleading message is thrown: "LDAP response read timed out, timeout used:-1ms.": https://bugs.openjdk.java.net/browse/JDK-8062947 The

Re: [15] RFR: 8243138: Enhance BaseLdapServer to support starttls extended request

Hi Chris, The changes look good to me. Thank you for extending the LDAP test server functionality. With Best Regards, Aleksei On 22/04/2020 08:27, Chris Yin wrote: Hello Please review following change for enhancement to com/sun/jndi/ldap/lib/BaseLdapServer.java, thanks Bug:

Re: [15] RFR: 8242614: cleanup duplicated test ldap server in some com/sun/jndi/ldap/ tests

Hi Chris, The changes looks good to me. Thanks for improving the tests! It's nice to see dummy LDAP servers replaced by the common test server skeleton. With Best Regards, Aleksei On 21/04/2020 08:43, Chris Yin wrote: Hello Please review following changes to cleanup duplicated test ldap

Re: [teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed

Daniel, Chris, Vyom, Thanks for your comments and reviews! About updating @bug tag: In general, I'm not adding the bug id if a fix is for the test itself, i.e. bug has 'noreg-self' label. - Aleksei On 08/12/2019 20:33, Chris Hegarty wrote: On 8 Dec 2019, at 10:48, Daniel Fuchs wrote: Hi

[teststabilization] RFR: 8141685: com/sun/jndi/ldap/InvalidLdapFilters.java initializes context failed

Hi, InvalidLdapFilters test has been seen failing intermittently with timeouts. The cause of the observed failures could be the binding of test server to the wildcard address. Proposed fix binds the test server to the loopback address and uses the test library to construct LDAP provider URL.

RFR(XS): 8232713: Update BCEL version to 6.3.1 in license file

Hi, The BCEL version has been updated to 6.3.1 by JDK-8224157 [1]. The BCEL license file needs to be updated to include the correct version. Webrev: http://cr.openjdk.java.net/~aefimov/8232713/00 JBS: https://bugs.openjdk.java.net/browse/JDK-8232713 With Best Regards, Aleksei [1]

Re: RFR[8229338]: clean up test/jdk/java/util/RandomAccess/Basic.java

Hey Patrick, I don't think that we need to add 8229338 to the bug line since it is just test refactoring issue (noreg-self). Otherwise, the changes look good to me! With Best Regards, Aleksei On 27/09/2019 15:53, Patrick Concannon wrote: Hi Lance, Thanks for your feedback. I've added in

[8u-dev] Request for review and approval for 8193830: Xalan Update: Xalan Java 2.7.2

Hello, Can I, please, have an approval to backport JDK-8193830 to jdk8u-dev? Webrev: http://cr.openjdk.java.net/~aefimov/8193830 JBS: https://bugs.openjdk.java.net/browse/JDK-8193830 JDK11 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051230.html JDK11 changeset:

[jdk8u-dev] RFR: 8196491: Newlines in JAXB string values of SOAP-requests are escaped to ""

Hello, Would you, please, review the fix for JAXWS regression bug [1] that has been introduced by a fix that tried to preserve whitespaces in WS parameters [2]. The proposed fix addresses the reported UnsupportedOperationException and brings the JDK7 and JDK8 in-sync in terms of white-space

Re: [11] RFR: (JAXP) 8038043: Xerces Update: XInclude update

better the next time. As for the tests, I'm fine with the encoding tests plus passing all existing ones. Best, Joe On 2/16/2018 9:53 AM, Aleks Efimov wrote: Hi, Please, help to review the update of XInclude related classes from the Apache Xerces 2.11.0 source. JBS:     https

[11] RFR: (JAXP) 8038043: Xerces Update: XInclude update

Hi, Please, help to review the update of XInclude related classes from the Apache Xerces 2.11.0 source. JBS:     https://bugs.openjdk.java.net/browse/JDK-8038043 The webrev:     http://cr.openjdk.java.net/~aefimov/8038043/11/00/ New regression test has been added to check the updated

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

-with-resources but in this case it does not add much because   exceptions can't occur when using BAOS. Thanks, Roger On 2/5/2018 9:46 PM, Aleks Efimov wrote: Thank you for your comments, Jason! New webrev can be found at this location: http://cr.openjdk.java.net/~aefimov/6857903/dev/02/ The list

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

ing on. That is just my preference though. Jason From: Aleks Efimov <aleksej.efi...@oracle.com> Sent: Monday, February 5, 2018 10:51 AM To: Jason Mehrens; 'Roger Riggs' Cc: core-libs-dev Subject: Re: RFR [11] (JAXP): 6857903: SAXException.initCau

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

oun...@openjdk.java.net> on behalf of Aleks Efimov <aleksej.efi...@oracle.com> Sent: Thursday, December 21, 2017 11:27 AM To: core-libs-dev Subject: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception Hello, Please, help to review the fix for jaxp bug that fixes

RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Hello, Please, help to review the fix for jaxp bug that fixes SAXException to correctly set exception cause with 'setCause' method: http://cr.openjdk.java.net/~aefimov/6857903/dev/00/ I've tried to keep the fix miminal with respect to serial form of this API class, i.e. kept private

Re: [10] RFR: 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class

Thank you Lance! Best, Aleksei On 11/29/2017 08:12 PM, Lance Andersen wrote: Hi Aleks, The changes look reasonable Best Lance On Nov 29, 2017, at 2:48 PM, Aleks Efimov <aleksej.efi...@oracle.com <mailto:aleksej.efi...@oracle.com>> wrote: https://bugs.openjdk.java.net/browse

[10] RFR: 8186441: Change of behavior in the getMessage () method of the SOAPMessageContextImpl class

Hi, Can I, please, ask for assistance with reviewing the JDK-8186441 fix [1]? Problem description: In JDK9 we've fixed SAAJ bug in JDK:     https://bugs.openjdk.java.net/browse/JDK-8159058 And this fix caused JDK-8186441 regression that resulted in breaking the namespace definitions in SOAP

[8u-dev][JAXB] Request for review and approval: 8159240: XSOM parser incorrectly processes type names with whitespaces

Hi, Can I, please, ask for review and approval of JDK-8159240 backport to JDK8? This bug was resolved in JDK9 as part of JAXWS-RI sync changeset (JDK-8164479) therefore separate review for the partially backported changes is needed: http://cr.openjdk.java.net/~aefimov/8159240/8/00/ File

Re: RFR: 8186314: code at c.s.x.i.m.saaj.soap.MessageImpl must be modified to avoid crash after javac change

Hi Vicente, The change looks good to me (not a reviewer). Best, Aleksei On 08/16/2017 09:47 PM, Vicente Romero wrote: Hi, Please review the fix for issue [1]. The fix can be found at [2]. The fix is minimal, reproduced below: ---

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

Lance, thanks for this review too! Best, Aleksei On 06/16/2017 07:20 PM, Lance Andersen wrote: Hi Aleks, This looks fine minus the request of Bill to revert. So no need to see the changes you reverted again Best Lance On Jun 16, 2017, at 12:17 PM, Aleks Efimov <aleksej.efi...@oracle.

Re: [8u-dev] RFR (JAXWS): 8172297: In java 8, the marshalling with JAX-WS does not escape carriage return

Thank you for the review, Lance! On 06/16/2017 07:22 PM, Lance Andersen wrote: Hi Aleks, The changes looked fine to me. Best Lance On Jun 9, 2017, at 10:10 AM, Aleks Efimov <aleksej.efi...@oracle.com <mailto:aleksej.efi...@oracle.com>> wrote: Hello, Please, help to re

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

Thank you, Mandy! Best, Aleksei On 06/16/2017 06:19 PM, Mandy Chung wrote: On Jun 16, 2017, at 9:17 AM, Aleks Efimov <aleksej.efi...@oracle.com> wrote: : 4. Update jdk/test/jdk/modules/etc/JdkQualifiedExportTest.java to remove "java.xml/com.sun.xml.internal.stream.wr

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

Hi Bill, Sure - will revert it. On 06/16/2017 06:05 PM, Bill Shannon wrote: Aleks Efimov wrote on 6/16/17 9:17 AM: 3. MimetypesFileTypeMap.java: - Are the Parens around lines 54-57 really needed? I think that the parens are not needed too. Removed them + also removed parens

Re: [8u-dev] RFR (JAXWS): 8172297: In java 8, the marshalling with JAX-WS does not escape carriage return

tting com.sun.xml.bind.characterEscapeHandler" or “com.sun.xml.bind.marshaller.CharacterEscapeHandler" properties on Marshaller. This is respected by XMLStreamWriterOutput escape handling. Roman On 9 Jun 2017, at 16:10, Aleks Efimov <aleksej.efi...@oracle.com> wrote: Hello, Please, help to review the

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

08 PM, Dmitry Kornilov <dmitry.korni...@oracle.com> wrote: Roman is on vacation this week and coming back next Tuesday, May 20. If we are in a hurry with this sync (and we are) I can ask Aleks Efimov to make these changes and commit it to JDK. —Dmitry On 13 Jun 2017, at 01:24, Lance Anderse

[8u-dev] RFR (JAXWS): 8172297: In java 8, the marshalling with JAX-WS does not escape carriage return

Hello, Please, help to review the fix that helps JAXWS marshaller to properly escape new-line and carriage return symbols in webservice string parameters: http://cr.openjdk.java.net/~aefimov/8172297/8/00 The source part of this fix is a partial backport of JAXWS-RI sync changes that

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

I'm sorry Lance! I'm uploading new version of the webrev right now to the same location :-) It should be on-line soon =) Best, Aleksei On 06/01/2017 06:34 PM, Lance Andersen wrote: Hi Roman, The webrev seems to have gotten moved as I was reviewing it and now it is gone :-) On May 31,

Re: JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

the System property is set. Best regards, Joe On 4/16/2017 3:02 PM, Aleks Efimov wrote: Hi, Please, help to review the fix [1] for a performance regression in SPECjvm2008-XML benchmark. The cause of this regression was the unconditional reset of SAX parsers symbol table during each reset

JDK 9 RFR: 8176168: Performance drop due to SAXParser SymbolTable reset

Hi, Please, help to review the fix [1] for a performance regression in SPECjvm2008-XML benchmark. The cause of this regression was the unconditional reset of SAX parsers symbol table during each reset() operation introduced by JDK-8173390. Proposed fix introduces new system property (CCC

Re: [9] RFR: 8173390: Investigate SymbolTable in SAXParser

Thank you Joe! On 16/02/17 03:07, huizhe wang wrote: Looks good to me. Thanks, Joe On 2/15/2017 3:56 PM, Aleks Efimov wrote: Hi Joe, Thank you for your suggestions. New webrev can be found here: http://cr.openjdk.java.net/~aefimov/8173390/9/01 Hi Daniel, You're right that assertNotSame

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

Hi, The new webrev with addressed comments was uploaded here: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8174735/01 Best, Aleksej On 15/02/17 15:42, Roman Grigoriadi wrote: Hi Mandy, On 02/14/2017 11:53 PM, Mandy Chung wrote: On Feb 14, 2017, at 4:00 AM, Roman Grigoriadi

[9] RFR: 8173390: Investigate SymbolTable in SAXParser

Hi, Please, help to review the change required by JAXWS-RI code [1]: SAXParser needs to reset internal SymbolTable to enable pooling of parsers in SAAJ-RI code. Latest version of JAXWS-RI code (that is currently under review [2]) doesn't provide a workaround to reset the symbol table (it was

Re: (JAXP) RFR: 8173111: Excessive recursion in EventFilterSupport when filtering over large number of XML events can cause StackOverflow

Hi Daniel, Lance, It looks like Assert.assertEquals(String actual, String expected, String message) suites better and lines 73-77 can be replaced with: assertEquals(sb.toString(), SMOKE, "Smoke test failed" ). And do we really need 'main' here? All test methods are annotated with @Test tags

Re: [9] RFR: 8159058: SAXParseException when sending soap message

, The changes seem reasonable. I am assuming that the JAXWS/SAAJ standalone tcks were run against the standalone RIs by the jaxws team? The JCK tests are a variation of the standalone tests so might be good to sanity check if not already done. Best Lance On Jan 9, 2017, at 4:34 AM, Aleks Efimov

[9] RFR: 8159058: SAXParseException when sending soap message

Hi, Please, help to review the JDK9 fix for the issue [1] in processing of default namespace attribute with empty values (xmlns="") by SAAJ implementation: http://cr.openjdk.java.net/~aefimov/8159058/9/00 Same fix was already integrated into JAXWS-RI and SAAJ-RI standalone projects. These

RFR(XS): 8067237: [TESTBUG] javax/xml/ws/xsanymixed/Test.java failed on compilation

Hello, Please, help to review javax/xml/ws/xsanymixed/Test.java test fix that addresses test failure [1] with JDK9 JRE runtime due to missing wsimport tool. The fix is to use the tool from compile JDK: http://cr.openjdk.java.net/~aefimov/8067237/9/00/ The modification was tested with

Re: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

Hi, Can I, please, ask JDK8 reviewer to look through the backported changes? Thanks, Aleksej On 15/12/16 17:06, Aleks Efimov wrote: Hi, Can I, please, have an approval to backport JDK-8146086 to 8u-dev. The source fix was slightly modified to remove stream/lamdba usages, therefore the fix

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

iPhone gesendet Am 14.12.2016 um 19:04 schrieb Aleks Efimov <aleksej.efi...@oracle.com>: Hi Joe, Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier' instead of 'String'? Such approach will give us a possibility

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

To: Aleks Efimov <aleksej.efi...@oracle.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance Hi Aleksej, Looks good. Thanks for covering the whole packages! Best, Joe On 12/14/16, 10:

[8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

Hi, Can I, please, have an approval to backport JDK-8146086 to 8u-dev. The source fix was slightly modified to remove stream/lamdba usages, therefore the fix is a subject to review. Webrev with 8u-dev changes: http://cr.openjdk.java.net/~aefimov/8146086/8/00/ The fix was tested with JPRT on

Re: Unexpected BindException in Endpoint.publish

<kubota.y...@gmail.com>: Hi Aleksej, Thank you very much! If you need some help about the patch, please mention me :) Thanks, Yuji 2016-08-03 19:56 GMT+09:00 Aleks Efimov <aleksej.efi...@oracle.com>: Hi Yuji, I've created JDK8 backport [1] for this issue and will work on it in

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

() 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) where similar problems exist. Best, Joe On 12/13/16, 3:02 PM, Aleks Efimov wrote: Hello, Please, help to review the changes that addresses the file system

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

Hello, Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block: http://cr.openjdk.java.net/~aefimov/8146271/9/00/ Best Regards,

[9] RFR(XXXXS): 8160999: GPL header missing comma in year

Hi, jaxws/src/java.xml.bind/share/classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition: diff -r

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

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 transformation process. JDK9 build that includes this fix was tested with JDK XML related

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

Hi Alan, Joe, Mandy, Roman, Suggested changes to the comment section (will bring this change to standalone JAXB) and to the exported internal API were made: com.sun.xml.internal.stream.writers, com.sun.org.apache.xml.internal.resolver, com.sun.org.apache.xml.internal.resolver.tools

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

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 tests

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

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 default now and because of that the default SAX

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

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 set the extension ClassLoader for the extension class. JBS:

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

can always be helpful in case of failures. Thanks, Joe On 8/30/16, 12:01 PM, Aleks Efimov wrote: Hello, Please, help to review the tests fix. Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 The list of changes: 1. Two tests were

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

he Lambda expression might be more consistent, too. I'm not a reviewer though... Best regards Christoph -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Aleks Efimov Sent: Dienstag, 30. August 2016 21:01 To: core-libs-dev <core-libs-dev@open

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

Hello, Please, help to review the tests fix. Webrev: http://cr.openjdk.java.net/~aefimov/8150145/00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8150145 The list of changes: 1. Two tests were modified to print exception occurred during execution. Before that these tests were failing

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

Hello, Please, help to review the JDK9 changes in JAXB XSOM parser that solves issue [0] with incorrectly collapsed namespaces within schema types names definitions/usages: http://cr.openjdk.java.net/~aefimov/8159240/9/00/ Problem description: The XMLSchema defines that whitespaces should be

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

To: Aleks Efimov <aleksej.efi...@oracle.com> Cc: core-libs-dev <core-libs-dev@openjdk.java.net> Subject: Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions Looks good, Aleksej. Thanks for coming up with a well-thought solution to get rid of the static RE field

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

; /** * Constructor AbortException */ public AbortException() { super(null, null, false, false); } } Regards, Peter On 08/17/2016 04:04 PM, Aleks Efimov wrote: Hi Joe, Aleksey, Thank you for reviewing the initial fix. I followed the Joe's suggestion (thanks for that) and removed static

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

message if error happens, and there's no handler or the handler failed to handle it. (would be better than an empty RE) Best, Joe On 8/15/16, 10:38 AM, Aleks Efimov wrote: Hi, Please, help to review the fix for memory leak [1] in com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused

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

Hi, Please, help to review the fix for memory leak [1] in com.sun.org.apache.xerces.internal.dom.DOMNormalizer that is caused by usage of static final exceptions. This problem was already fixed in Apache Xerces project [2] and I would like to backport it to JDK9 Xerces implementation. Webrev

Re: Unexpected BindException in Endpoint.publish

Hi Yuji, I've created JDK8 backport [1] for this issue and will work on it in the upcoming months. Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8162941 On 02/08/16 08:33, KUBOTA Yuji wrote: Hi all, Could you let me know when this fix will be backport to JDK 8? We

Re: RFR (JAXP): 8148350: Element.setAttributeNS() empty namespace does not throw exception

e good to update the relevant Javadoc to reflect the change since this part of Javadoc is quite explicit about when NAMESPACE_ERR is thrown. Also, this is a good opportunity to update the Lic header. Thanks, Joe On 7/12/2016 11:04 AM, Aleks Efimov wrote: Hi, Please, help to review t

RFR (JAXP): 8148350: Element.setAttributeNS() empty namespace does not throw exception

Hi, Please, help to review the fix for org.w3c.dom.Element#setAttributeNS method in JDK9: According to w3.org documentation empty string cannot be used as a namespace name [1]. Therefore the setAttributeNS [2] should raise DOMException (NAMESPACE_ERR) when namespaceURI is empty string (similar

Re: [9] RFR: 8154553: Incorrect GPL header in package-info.java reported

(c) 2011 Oracle and/or its affiliates. All rights reserved. sample/share/nio/chatserver/MessageReader.java: * Copyright (c) 2011 Oracle and/or its affiliates. All rights reserved. I'd prefer to see them fixed all at once, if possible. With kind regards, Ivan On 05.07.2016 1:39, Aleks Efimov

[9] RFR: 8154553: Incorrect GPL header in package-info.java reported

Hello, jdk/src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/package-info.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition:

Re: Review request JDK-8153944: wsimport and wsgen usage messages not printed

Hi Mandy, Looks good to me. Best Regards, Aleksej On 25/05/16 22:48, Mandy Chung wrote: On May 25, 2016, at 12:45 PM, Alan Bateman wrote: On 25/05/2016 20:29, Mandy Chung wrote: wsgen and wsimport tools use the utility classes in java.xml.bind module to localize

RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg

Hi, Please review the changes to test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java: 1. The test is skipped by JTREG due to incorrect module name in jtreg @modules tag: javax.xml.bind -> java.xml.bind 2. The compilation of XJC generated classes now requires "-addmods java.xml.bind"

RFR [9]: 8072579: XjcOptionalPropertyTest.java creates files in test.src

Hi, Please, help to review XjcOptionalPropertyTest test modification bug [1]. The list of applied changes: 1. Test files are now generated in jtreg work directory (scratch), instead of test source folder. 2. Shell script was replaced with java code: xjc tool is now invoked via

Re: [9] RFR: 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter

test. Also, would the content read is the same (vs contains) as the expectedContent? "writer.close()" was added and 'contains' was replaced with testng's assertEquals. Thanks, Joe On 5/11/2016 4:30 PM, Aleks Efimov wrote: Hello, Please, help to review the fix for XMLStreamWriter

[9] RFR: 8145974: XMLStreamWriter produces invalid XML for surrogate pairs on OutputStreamWriter

Hello, Please, help to review the fix for XMLStreamWriter bug [1]: XMLStreamWriter incorrectly writes surrogate pairs into pair of invalid character references. For example: "\ud83d\ude0a" is transformed into "". It should be one character reference "" instead. The proposed patch fixes the

[9] RFR: 8152927: Incorrect GPL header in StubFactoryDynamicBase.java reported

Hello, corba/src/java.corba/share/classes/com/sun/corba/se/impl/presentation/rmi/StubFactoryDynamicBase.java file contains incorrect GPL header which fails make/scripts/lic_check.sh script check with such error: ### Checking copyright notice in the file: