[7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException

2012-07-09 Thread Joe Wang
, at 11:59 PM, Joe Wang wrote: Hi Paul, That method was contributed by engineers from Korea and intended to handle paths that contained international characters, so that was how it was named. It was an extra processing added. Outside of that scenario, we'd want to skip the process and get back

Re: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException

2012-07-10 Thread Joe Wang
On 7/9/2012 10:59 PM, Paul Sandoz wrote: Hi Joe, What happens when someone logs a bug for system IDs containing IPv6 addresses and non-percent encoded international characters? Exception would be expected just as if Xerces is used. On Jul 10, 2012, at 3:42 AM, Joe Wang wrote: Hi Paul

Re: [7u8] [Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException

2012-07-10 Thread Joe Wang
/2012 12:26 PM, Paul Sandoz wrote: Hi Joe, If you are gonna fix things to support IPv6 addresses in URLs i really think you need to make it work for URLs with international characters too. On Jul 10, 2012, at 8:50 PM, Joe Wang wrote: 602 if (reader == null) { 603 stream

Re: RFR [7u8]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException

2012-07-12 Thread Joe Wang
Lance, Paul, Thanks! Joe On 7/12/2012 3:55 AM, Lance Andersen - Oracle wrote: +1 Best Lance On Jul 12, 2012, at 5:42 AM, Paul Sandoz wrote: Hi Joe, On Jul 11, 2012, at 7:59 AM, Joe Wang wrote: Hi Paul, This is now for 7u8, so I started a new thread. As we discussed, I've removed

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-07-30 Thread Joe Wang
Hi Paul, Alan, I'm back on this change. On 6/25/2012 12:19 PM, Joe Wang wrote: On 6/25/2012 9:34 AM, Paul Sandoz wrote: H Joe, I just focused on javax.xml.datatype and assumed the rest follows the same pattern :-) Yeah, they are mostly similar, except Schema and XPath that do a little

RFR [7u8] (JAXP): 7191547 : XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected

2012-08-16 Thread Joe Wang
In the patch for 6756677, we fixed errors in StAX's input and output factories where factoryId such as 'javax.xml.stream.XMLInputFactory was taken as factory class e.g. com.sun.xml.internal.stream.XMLInputFactoryImpl. Unfortunately, we missed XMLEventFactory in that patch. So this is a

Re: RFR [7u8] (JAXP): 7191547 : XMLEventFactory.newFactory(String factoryId, ClassLoader loader) does not work as expected

2012-08-17 Thread Joe Wang
Thanks, Lance! On 8/17/2012 8:26 AM, Lance Andersen - Oracle wrote: Hi Joe, Looks fine. Best Lance On Aug 17, 2012, at 12:07 AM, Joe Wang wrote: In the patch for 6756677, we fixed errors in StAX's input and output factories where factoryId such as 'javax.xml.stream.XMLInputFactory

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-24 Thread Joe Wang
2) In factory finders: replaced findJarServiceProvider with findServiceProvider 3) In factory finders: removed ConfigurationError class, using FactoryConfigurationError instead Please review. Thanks, Joe On 7/29/2012 11:59 PM, Joe Wang wrote: Hi Paul, Alan, I'm back on this change

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-27 Thread Joe Wang
On 8/27/2012 6:19 AM, Alan Bateman wrote: On 24/08/2012 17:52, Joe Wang wrote: Hi, Here is a modified patch: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ The factory finders contain some format changes, a NetBeans format work. The real changes are as the follows: 1) In factory

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-27 Thread Joe Wang
On 8/27/2012 6:19 AM, Paul Sandoz wrote: Hi Joe, This is starting to look cleaner. Yeah, if Alan hasn't asked, I'd sooner keep them as they were :) JAXP is old, I never fancied getting those formats corrected. But I can't do this much to classes I'd update, but probably not to the impl

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-28 Thread Joe Wang
On 8/28/2012 1:19 AM, Paul Sandoz wrote: Hi Joe, On Aug 28, 2012, at 7:35 AM, Joe Wanghuizhe.w...@oracle.com wrote: -- datatype/FactoryFinder.java: 244 } catch (ServiceConfigurationError e) { 245 throw new DatatypeConfigurationException(e.getMessage(),

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-29 Thread Joe Wang
I actually updated the webrev yesterday with your suggestion. Recall our discussions back in June, the suggestion was to delegate to the ServiceLoader, e.g. ServiceLoader.load(serviceClass). The rational was that the ServiceLoader uses context and then bootstrap class loader. The spec for

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-29 Thread Joe Wang
Paul, Alan, Confusion was what jaxp meant to give :) I was told that the factory/object finders, security support classes were duplicated, and needed to be kept in sync. But they are not even in their original form, unfortunately. Both of you mentioned that it's desirable to make SCE the

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-30 Thread Joe Wang
ServiceLoader? --Joe On 8/29/2012 3:27 AM, Alan Bateman wrote: On 28/08/2012 05:57, Joe Wang wrote: : In DocumentBuilderFactory and SAXParserFactory the javadoc reads Otherwise the default implementation is returned if it is on the classpath or installed as a module. I think this statement

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-30 Thread Joe Wang
Hi Paul, Alan, I've read your latest comments. Before getting back to you on those items, I felt it's important we get the classloader handling correctly. If it's as what I suspected (as I described in the last email), we may have problem with using ServiceLoader. I've read Paul's

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-31 Thread Joe Wang
On 8/30/2012 2:20 PM, Alan Bateman wrote: On 30/08/2012 19:38, Joe Wang wrote: Hi Paul, Alan, I've read your latest comments. Before getting back to you on those items, I felt it's important we get the classloader handling correctly. If it's as what I suspected (as I described in the last

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-08-31 Thread Joe Wang
On 8/31/2012 4:20 AM, Alan Bateman wrote: On 31/08/2012 08:59, Joe Wang wrote: Yes, it works just fine under normal conditions. Note the old process: read the service file using TCCL (if null, system cl), if nothing found, then BCL Somehow I was under the impression ServiceLoader does

JAXP RFR: 8000172 : 2 SAX features does not work properly

2012-10-08 Thread Joe Wang
This is an issue found while I was working with SQE to expand test coverage. For a non-validating parser, when load-external-dtd is false, entity references are skipped. However, the skippedEntity() event was not reported. The problem was due to missing infoset augmentations when document

Re: JAXP RFR: 8000172 : 2 SAX features does not work properly

2012-10-09 Thread Joe Wang
Thanks Lance! On 10/9/2012 7:55 AM, Lance Andersen - Oracle wrote: Look OK Joe On Oct 9, 2012, at 12:31 AM, Joe Wang wrote: This is an issue found while I was working with SQE to expand test coverage. For a non-validating parser, when load-external-dtd is false, entity references

Re: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-05 Thread Joe Wang
Hi Daniel, Looks good to me! -Joe On 12/5/2012 8:17 AM, Daniel Fuchs wrote: Hi, Please find below a revised version of the changes for the javax.xml.parsers package. It hopefully incorporates all comments I have received so far.

Re: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-07 Thread Joe Wang
I would think that it's good to merge the 3rd and 4th steps for a jdk in module mode. In regular mode or JDK8, where the existence of the default implementation is guaranteed, the last step is still necessary. It is a requirement for the API implementation. I probably was wrong to use

Re: 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present

2012-12-07 Thread Joe Wang
Thanks for reviewing the changes. Please see comments inline. On 12/7/2012 11:38 AM, Mandy Chung wrote: On 12/5/12 10:58 AM, Alan Bateman wrote: http://cr.openjdk.java.net/~alanb/8004371/webrev/ Yay! Properties no longer requires JAXP to be present in order to load/store properties in

Re: CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-10 Thread Joe Wang
Hi Daniel, Looks good! Joe On 12/10/2012 9:12 AM, Daniel Fuchs wrote: Hi, After further discussion with Joe Alan, I changed the call to ServiceLoader to simply return the first provider it finds, or null. This is closer to what was present in JDK 7 - and looping is not necessary in JDK 8

Re: code review request : 8003147 port fix for BCEL bug 39695

2012-12-12 Thread Joe Wang
Review for jaxp ] http://cr.openjdk.java.net/~dbuck/8003147/webrev.00/ My understanding is that the test cases for our copy of the jaxp code are handled in a separate repository / test suite. I have been in contact with Patrick Zhang (Oracle QA) and Joe Wang and have provided a junit test

Re: RFR: javax.xml.datatype: Using ServiceLoader to load JAXP datatype factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-13 Thread Joe Wang
Hi Daniel, This looks good. We had some discussion over if there's a difference in classloading between the original sequence and that of ServiceLoader. I understand you have the full regression testsuite from SQE. Just would like to make sure they pass just fine. Thanks, Joe On

Re: 8004371: (props) Properties.loadFromXML needs small footprint XML parser as fallback when JAXP is not present

2012-12-13 Thread Joe Wang
On 12/12/2012 2:35 AM, Alan Bateman wrote: On 12/12/2012 09:31, Paul Sandoz wrote: http://cr.openjdk.java.net/~alanb/8004371/webrev.02/src/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java.html Why are the element qualified names compared ignoring case? I'll leave this

Re: code review request : 8003147 port fix for BCEL bug 39695

2012-12-14 Thread Joe Wang
be easier for one of you to run the tests yourself. You may ask Patrick for instructions on how to run regression test. It needs to be run separately since they are not in the jdk repo yet. Thanks, Joe Cheers, -Buck On 2012/12/13 4:14, Joe Wang wrote: Hi David, You didn't apply the original

RFR: (jaxp) 8003260 : some fields should be package protected

2012-12-14 Thread Joe Wang
Hi, This is one of the three [findbug] issues. I've checked with Drew. None of them are vulnerabilities. Nonetheless, the fields should have been private or package private. webrev: http://cr.openjdk.java.net/~joehw/7u12/8003260/webrev/ Test: No new test. Existing regression tests passed.

Re: RFR: (jaxp) 8003260 : some fields should be package protected

2012-12-14 Thread Joe Wang
Best Lance On Dec 14, 2012, at 1:33 PM, Joe Wang wrote: Hi, This is one of the three [findbug] issues. I've checked with Drew. None of them are vulnerabilities. Nonetheless, the fields should have been private or package private. webrev: http://cr.openjdk.java.net/~joehw/7u12/8003260/webrev

Re: RFR: (jaxp) 8003260 : some fields should be package protected

2012-12-14 Thread Joe Wang
it is fine Best Lance On Dec 14, 2012, at 1:33 PM, Joe Wang wrote: Hi, This is one of the three [findbug] issues. I've checked with Drew. None of them are vulnerabilities. Nonetheless, the fields should have been private or package private. webrev: http://cr.openjdk.java.net/~joehw/7u12/8003260

RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
Hi, This is the 2nd of the three [findbug] issues. The field fVersion is simply made final. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/ Test: No new test needed. Thanks, Joe

Re: RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
Thanks Chris! On 12/18/2012 12:53 AM, Chris Hegarty wrote: Looks ok to me Joe. -Chris On 18 Dec 2012, at 08:47, Joe Wanghuizhe.w...@oracle.com wrote: Hi, This is the 2nd of the three [findbug] issues. The field fVersion is simply made final. webrev:

Re: RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
On 12/18/2012 12:55 AM, David Holmes wrote: Joe, On 18/12/2012 6:47 PM, Joe Wang wrote: Hi, This is the 2nd of the three [findbug] issues. The field fVersion is simply made final. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/ Obviously it was known

Re: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-18 Thread Joe Wang
Hi Daniel, The call: T provider = findServiceProvider(type) in static T T find(ClassT type, String factoryId, ClassLoader cl, String fallbackClassName) ignored factoryId, and assumed it's the same as type.getName(). I looked back I had the same bug in my original patch. -Joe On 12/18/2012

Re: RFR: javax.xml.transform: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-18 Thread Joe Wang
Hi Daniel, Looks great! I see you've added many verifications. One minor note, creationMethod is used in place of the object instance for the creationMethod.invoke call, although it's ignored for a static method anyways. Is there a reason for doing that? -Joe On 12/18/2012 8:42 AM,

Re: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-18 Thread Joe Wang
On 12/18/2012 10:00 AM, Daniel Fuchs wrote: On 12/18/12 6:29 PM, Joe Wang wrote: Hi Daniel, The call: T provider = findServiceProvider(type) in static T T find(ClassT type, String factoryId, ClassLoader cl, String fallbackClassName) ignored factoryId, and assumed it's the same

Re: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-18 Thread Joe Wang
On 12/18/2012 2:23 PM, Daniel Fuchs wrote: On 12/18/12 8:00 PM, Joe Wang wrote: On 12/18/2012 10:00 AM, Daniel Fuchs wrote: On 12/18/12 6:29 PM, Joe Wang wrote: Hi Daniel, The call: T provider = findServiceProvider(type) in static T T find(ClassT type, String factoryId, ClassLoader cl

Re: RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
it may be a good idea to add the final, but make it a non-compile time constant. We can also remove the duplication. public static final String fVersion = getVersion(); Tom On 18/12/2012 08:47, Joe Wang wrote: Hi, This is the 2nd of the three [findbug] issues. The field fVersion

Re: RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
= getVersion(); Tom On 18/12/2012 08:47, Joe Wang wrote: Hi, This is the 2nd of the three [findbug] issues. The field fVersion is simply made final. webrev: http://cr.openjdk.java.net/~joehw/jdk8/8003261/webrev/ Test: No new test needed. Thanks, Joe

Re: RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
Network Drive x-apple-data-detectors://28/0 Burlington, MA 01803 x-apple-data-detectors://28/0 lance.ander...@oracle.com mailto:lance.ander...@oracle.com Sent from my iPhone On Dec 18, 2012, at 8:51 PM, Joe Wang huizhe.w...@oracle.com mailto:huizhe.w...@oracle.com wrote: Thanks Tom. I changed

Re: RFR: (jaxp) 8003261 : static field is public but not final

2012-12-18 Thread Joe Wang
On 12/18/2012 7:08 PM, David Holmes wrote: On 19/12/2012 12:21 PM, Joe Wang wrote: On 12/18/2012 3:43 PM, David Holmes wrote: On 19/12/2012 3:49 AM, Tom Hawtin wrote: Not that it's particularly important, but it's /possible/ clients are relying on the non-compile time constant nature

Re: RFR: javax.xml.transform: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

2012-12-19 Thread Joe Wang
On 12/19/2012 6:34 AM, Daniel Fuchs wrote: Hi, Please find below an updated webrev for the javax.xml.transform package, taking into account Mandy's Joe's comments - namely: 1. Fixed call to creationMethod.invoke. 2. Got rid of the 4 args FactoryFinder.newInstance method. 3. Got rid of the

RFR 8005281: (props) loadFromXML with small XML parser provider does not detect bad DOCTYPE

2012-12-21 Thread Joe Wang
The cause of the LoadAndStoreXML test failure appeared to be that of 8005281 that Alan just fixed. Before the 8005281 patch, I was able to get the tests to pass when I isolated the relevant tests (that is, copy LoadAndStoreXML and remove other test cases). After the 8005281 patch,

Re: RFR 8005280: (props) Improve test coverage for small XML parser

2012-12-21 Thread Joe Wang
On 12/21/2012 4:05 AM, Alan Bateman wrote: On 21/12/2012 08:37, Joe Wang wrote: The cause of the LoadAndStoreXML test failure appeared to be that of 8005281 that Alan just fixed. Before the 8005281 patch, I was able to get the tests to pass when I isolated the relevant tests (that is, copy

Re: RFR 8005280: (props) Improve test coverage for small XML parser

2012-12-21 Thread Joe Wang
On 12/21/2012 11:08 AM, Alan Bateman wrote: On 21/12/2012 18:03, Joe Wang wrote: : Files are renamed. I added a new test CompatibilityTest to test behavior compatibility with the regular JDK XML provider. Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005280/webrev/ -Joe Thanks

Re: RFR 8005280: (props) Improve test coverage for small XML parser

2012-12-21 Thread Joe Wang
On 12/21/2012 12:35 PM, Alan Bateman wrote: On 21/12/2012 19:56, Joe Wang wrote: : I searched by properties.dtd and found the CDATA usage. So I went ahead experimenting what would not be rejected by the regular provider and tested against the small parser. I agree the cases other than

RFR: (jaxp) 8005473 : Warnings compiling jaxp

2012-12-26 Thread Joe Wang
Hi, This is a patch to clean up compiling warnings in jaxp. Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473 Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/ Thanks, Joe

Re: RFR: (jaxp) 8005473 : Warnings compiling jaxp

2012-12-27 Thread Joe Wang
Thanks all! I've updated the webrev with Remi's suggestion. -Joe On 12/27/2012 5:25 AM, Remi Forax wrote: On 12/27/2012 12:06 AM, Joe Wang wrote: Hi, This is a patch to clean up compiling warnings in jaxp. Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473 Webrev: http

Re: RFR: (jaxp) 8005473 : Warnings compiling jaxp

2013-01-03 Thread Joe Wang
On 1/3/2013 3:33 AM, Daniel Fuchs wrote: On 12/27/12 12:06 AM, Joe Wang wrote: Hi, This is a patch to clean up compiling warnings in jaxp. Bug: http://bugs.sun.com/view_bug.do?bug_id=8005473 Webrev: http://cr.openjdk.java.net/~joehw/jdk8/8005473/webrev/ Thanks, Joe Hi Joe

Re: RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

2013-01-04 Thread Joe Wang
with existing code, I am sorely tempted to recommend that we do 3. and clarify the spec on this point. (3: Only call ServiceLoader.load(type) when the provided factoryId is equal to type.getName()) Best regards, -- daniel On 12/19/12 10:45 AM, Daniel Fuchs wrote: On 12/19/12 12:10 AM, Joe Wang wrote

Re: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader)

2013-01-11 Thread Joe Wang
for that purpose. I've taken an initial look at this and I'm wondering about SchemeFactory.newInstance throwing SchemaFactoryConfigurationError. Technically this is an incompatible change but in practical terms it may not be concern as this provider interface may not be used very much. Joe Wang

Re: RFR: javax.xml.validation: Using ServiceLoader to load JAXP schema factories (7169894: JAXP Plugability Layer: using service loader)

2013-01-11 Thread Joe Wang
On 1/11/2013 11:14 AM, Daniel Fuchs wrote: On 1/11/13 8:05 PM, Joe Wang wrote: I don't have any data on how much the service mechanism may be used, Xerces would surely be the one most frequently used. I'm more concerned with the spec change that would require TCK change (the addition

Re: Review Request for JDK-8007389: Remove uses of _ as identifier in jaxp

2013-02-04 Thread Joe Wang
Hi Eric, The change is fine. Thanks for taking on fixing this! Joe On 2/1/2013 3:19 PM, Eric McCorkle wrote: Thanks. Do I have a second? On 02/01/13 12:04, Lance Andersen - Oracle wrote: Its OK. Not sure I would have replaced it with 'unused' but not a big deal as it is just a personal

Re: JDK-8011653: Upgrade to JAXP 1.5

2013-04-15 Thread Joe Wang
On 4/8/2013 5:24 AM, Alan Bateman wrote: On 08/04/2013 08:39, huizhe wang wrote: Hi Lance, Alan, As I mentioned, I'd like to propose an integration of JAXP 1.5 into JDK8. JAXP 1.5 adds a new feature to control connections. Here's the webrev:

Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle

2011-03-02 Thread Joe Wang
Kelly, Thanks for the quick action! So I may even have time to handle any regressions before my vacation :) I double-checked both paths, and also the checksum. They are all good to me. Thanks, Joe On 3/2/2011 11:38 AM, Kelly O'Hair wrote: Need reviewer for change in jaxp source drop

Re: Need reviewers: Update of jaxp 1.4.5 source drop bundle

2011-04-12 Thread Joe Wang
Sorry for the late answer to this question. I was on a long vacation. Please see inline below. On 4/7/2011 7:04 AM, Dalibor Topic wrote: On 4/7/11 3:49 PM, Dr Andrew John Hughes wrote: On 07/04/2011, Dalibor Topic dalibor.to...@oracle.com wrote: On 3/3/11 3:01 AM, Dr Andrew John

Re: JAXP 1.4.5 in JDK7

2011-05-09 Thread Joe Wang
: http://jaxp.java.net/ you'll see that the latest formal release mentioned is 1.4.4. Is JDK7 going to ship with a development release of JAXP or will 1.4.5 get formally released before JDK7 FCS? I've cc'ed Joe Wang from the JAXP project and I'm sure he can help (and maybe suggest the mailing

7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2011-12-23 Thread Joe Wang
Hi All, We have prepared a jaxp update for 7u4. The listed changes have been posted to the jdk7u-dev alias with 7u4 Request for approval for CR 7121110 - JAXP 1.4.5 update 1 for 7u4. With this update, we are adding jaxp sources back into the jdk7 repository, which means we are abandoning

Re: 7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2011-12-23 Thread Joe Wang
On 12/23/2011 2:11 PM, Omair Majid wrote: On 12/23/2011 04:27 PM, Joe Wang wrote: Hi All, We have prepared a jaxp update for 7u4. The listed changes have been posted to the jdk7u-dev alias with 7u4 Request for approval for CR 7121110 - JAXP 1.4.5 update 1 for 7u4. With this update, we

Re: 7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2011-12-27 Thread Joe Wang
O'Hair wrote: Looks great to me. There is still the issue of making sure the right people (like you :^) are the ones patching this code, so we know what we have matches the public JAXP project. -kto On Dec 23, 2011, at 1:27 PM, Joe Wang wrote: Hi All, We have prepared a jaxp update for 7u4

Re: 7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2011-12-27 Thread Joe Wang
are in the same repository. But we can deal with that when the time comes. -kto On Dec 27, 2011, at 10:21 AM, Joe Wang wrote: Thanks Kelly! Indeed, that was the original intention when you designed the bundle process. Besides the unfortunate download problem, it actually works great in terms

Re: 7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2011-12-28 Thread Joe Wang
On 12/28/2011 2:56 AM, Alan Bateman wrote: On 23/12/2011 21:27, Joe Wang wrote: Hi All, We have prepared a jaxp update for 7u4. The listed changes have been posted to the jdk7u-dev alias with 7u4 Request for approval for CR 7121110 - JAXP 1.4.5 update 1 for 7u4. With this update, we

Re: 7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2011-12-30 Thread Joe Wang
On 12/30/2011 6:14 AM, Alan Bateman wrote: On 28/12/2011 17:18, Joe Wang wrote: Kelly asked for 6-open and jdk8 as well. Since we're changing the jaxp bundle process, we thought we would do the same for 6-open and jdk8 once this works out. But we can take the change to jdk8 first

Re: 7121110 : JAXP 1.4.5 update 1 for 7u4 jaxp source in jdk7 repo

2012-01-03 Thread Joe Wang
that fate. And maybe, this could be a tiny tiny tiny bit of it - no one knows, but since no one else has done it, we can claim that that was it when 12/13 comes ;-) -Joe -kto On Dec 30, 2011, at 10:11 AM, Joe Wang wrote: On 12/30/2011 6:14 AM, Alan Bateman wrote: On 28/12/2011 17:18

Review request for 7133220: Additional patches to JAXP 1.4.5 update 1 for 7u4

2012-01-27 Thread Joe Wang
Hi, With this additional patch, I'm fixing a SpecJvm2008 failure against 7u4 b07 (7098746), along with a couple of other fixes and accumulated Xalan update. The changes are listed below and at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7133220. The webrev is at:

Review request for 7133220: Additional patches to JAXP 1.4.5 update 1 for 7u4

2012-01-31 Thread Joe Wang
require a bit of effort. -Alan On 27/01/2012 23:05, Joe Wang wrote: / Hi, // // With this additional patch, I'm fixing a SpecJvm2008 failure against // 7u4 b07 (7098746), along with a couple of other fixes and accumulated // Xalan update. The changes are listed below and at // http

Please review: 7143711 : Feature added by 7053556 should not override what's set by the constructor in secure mode

2012-02-08 Thread Joe Wang
Hi, The 7053556 patch added a (Oracle) implementation-only feature to allow users to skip the plugability layer. In the same patch, there was also a change that in secure mode, dependent components should be loaded in a hardwired mode. The implementation-only feature therefore should not

Re: Please review: 7143711 : Feature added by 7053556 should not override what's set by the constructor in secure mode

2012-02-13 Thread Joe Wang
Thanks Tom. Joe On 2/13/2012 8:54 AM, Tom Hawtin wrote: Looks good to me. Tom On 08/02/2012 22:13, Joe Wang wrote: Hi, The 7053556 patch added a (Oracle) implementation-only feature to allow users to skip the plugability layer. In the same patch, there was also a change that in secure mode

RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

2012-03-05 Thread Joe Wang
Hi all, This is a low risk, proven patch made in Xerces back in 2007 [1], removing unnecessary synchronization in DTDDVFactory. As reported in 7147666, this patch improves performance in one of the xml test. Webrev : http://cr.openjdk.java.net/~joehw/7u4/cr7147666/webrev/ [1]

Re: RFR 7147666 : High lock time for com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance()

2012-03-05 Thread Joe Wang
the class to show up in any future diff operation. -Joe On 3/5/2012 1:02 PM, Lance Andersen - Oracle wrote: looks ok joe -lance On Mar 5, 2012, at 1:46 PM, Joe Wang wrote: Hi all, This is a low risk, proven patch made in Xerces back in 2007 [1], removing unnecessary synchronization

Re: RFR (7u4) 7150637: No newline emitted after XML decl in XSLT output

2012-03-20 Thread Joe Wang
*/ Corrected the typo: is should have been if The updated webrev: http://cr.openjdk.java.net/~joehw/7u4/cr7150537/webrev/ http://cr.openjdk.java.net/%7Ejoehw/7u4/cr7150537/webrev/ Regards, Joe Best lance On Mar 20, 2012, at 1:32 PM, Joe Wang wrote: Hi, This is an issue introduced

Re: RFR (7u4) 7150637: No newline emitted after XML decl in XSLT output

2012-03-21 Thread Joe Wang
Thanks for the quick review! Now, if only I can get the approval today, I can actually catch the code freeze... :) --Joe On 3/21/2012 5:26 AM, Lance Andersen - Oracle wrote: Thank you Joe, good to go from my perspective. Best Lance On Mar 20, 2012, at 11:36 PM, Joe Wang wrote: Thanks

RFR 7151484 : NullPointerException caused by a bug in XMLDocumentFragmentScannerImpl

2012-03-30 Thread Joe Wang
Hi, This is a one line fix: adding a return statement as suggested in the bug report to guard against null value of the name parameter. webrev: http://cr.openjdk.java.net/~joehw/7u6/cr7151484/webrev/ Please review. Thanks, Joe

Re: RFR 7151484 : NullPointerException caused by a bug in XMLDocumentFragmentScannerImpl

2012-03-30 Thread Joe Wang
Thanks! On 3/30/2012 5:41 AM, Lance Andersen - Oracle wrote: Hi Joe, Looks fine -lance On Mar 30, 2012, at 3:24 AM, Joe Wang wrote: Hi, This is a one line fix: adding a return statement as suggested in the bug report to guard against null value of the name parameter. webrev: http

New reviewers: 7160496 : Rename JDK8 JAXP source directory

2012-04-10 Thread Joe Wang
After removing the jaxp source drop bundle process, refer to 7150324, the source structure needs to be changed to be consistent with that of jdk7. I will rename jdk8/jaxp/src/share/classes to jdk8/jaxp/src before updating it to the current jaxp source (7160380). webrev for the build files:

RFR [JDK8]: 7160380 Sync JDK8 with JAXP 1.4.5

2012-04-12 Thread Joe Wang
This is a follow-up update on Kelly's change that dropped the jaxp source drop bundle process. With this update, the jaxp source in JDK8 will be sync-ed with the current JAXP 1.4.5, and also JDK7u (the last change was 7151484). Going forward, we'll follow the process to put any changes into

[7u6] RFR : 7161105 : unused classes in jdk7u repository

2012-04-13 Thread Joe Wang
In the patch for 7053556, the ObjectFactory/SecuritySupport classes that were duplicated in many packages were replaced by a unified set under xerces/internal/utils and xalan/internal/utils (Note that those under xpath/internal/utils were old). When the jaxp 1.4.5 source bundle was dropped

Re: [7u6] RFR : 7161105 : unused classes in jdk7u repository

2012-04-13 Thread Joe Wang
I'd thank them for the services over the last 8 years :) On 4/13/2012 2:08 PM, Lance Andersen - Oracle wrote: looks good joe, say goodbye to them :-) On Apr 13, 2012, at 1:17 PM, Joe Wang wrote: In the patch for 7053556, the ObjectFactory/SecuritySupport classes that were duplicated in many

Re: RFR [JDK8]: 7160380 Sync JDK8 with JAXP 1.4.5

2012-04-16 Thread Joe Wang
On 4/16/2012 7:20 AM, Sean Mullan wrote: On 4/12/12 6:25 PM, Joe Wang wrote: This is a follow-up update on Kelly's change that dropped the jaxp source drop bundle process. With this update, the jaxp source in JDK8 will be sync-ed with the current JAXP 1.4.5, and also JDK7u (the last change

Re: RFR [JDK8]: 7160380 Sync JDK8 with JAXP 1.4.5

2012-04-16 Thread Joe Wang
I've added the testcase. The new webrev is here: http://cr.openjdk.java.net/~joehw/jdk8/7160380/jdk/webrev/ Also, Lance has reviewed the long list of the source changes. Thanks! -Joe On 4/16/2012 7:20 AM, Sean Mullan wrote: On 4/12/12 6:25 PM, Joe Wang wrote: This is a follow-up update

[7u6] RFR (JAXP) : 7157608: One feature is not recognized.

2012-06-07 Thread Joe Wang
The feature is: http://apache.org/xml/features/standard-uri-conformant True: Requires that a URI has to be provided where a URI is expected. False: Some invalid URI's are accepted as valid values when a URI is expected. Examples include: using platform dependent file separator in

Re: Fwd: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly

2012-06-08 Thread Joe Wang
Lance, It looks fine to me. Best, Joe On 6/5/2012 7:16 AM, Lance Andersen - Oracle wrote: Looking for a reviewer here as well still Best Lance Begin forwarded message: From: Lance Andersen - Oraclelance.ander...@oracle.com Date: May 26, 2012 9:33:40 AM EDT Cc: core-libs-dev

[7u6] RFR (JAXP) : 7157610: NullPointerException occurs when parsing XML doc

2012-06-11 Thread Joe Wang
As reported in 7157610, when setFeature(http://apache.org/xml/features/disallow-doctype-decl;, true) is set on SAXParserFactory object, XMLReader object or DocumentBuilderFactory object, NullPointerException will be thrown when parsing XML document that has DOCTYPE declaration. The cause of

Re: [7u6] RFR (JAXP) : 7157610: NullPointerException occurs when parsing XML doc

2012-06-11 Thread Joe Wang
//return fSupportDTD? next() : dtdEvent; in XMLDocumentScannerImpl? If not you might consider removing it. Best Lance On Jun 11, 2012, at 3:08 PM, Joe Wang wrote: As reported in 7157610, when setFeature(http://apache.org/xml/features/disallow-doctype-decl;, true) is set on SAXParserFactory

[7u6] RFR (JAXP) : 7144423: StAX EventReader swallows the cause of error

2012-06-11 Thread Joe Wang
Hi, This is patch to make sure the cause of the error is properly reported. It has been in jaxp since Feb. webrev: http://cr.openjdk.java.net/~joehw/7u6/7143711/webrev/ Please review. Thanks, Joe

Re: [7u6] RFR (JAXP) : 7144423: StAX EventReader swallows the cause of error

2012-06-12 Thread Joe Wang
Thanks Lance, Paul! Joe On 6/12/2012 5:48 AM, Lance Andersen - Oracle wrote: looks fine best lance On Jun 11, 2012, at 7:23 PM, Joe Wang wrote: Hi, This is patch to make sure the cause of the error is properly reported. It has been in jaxp since Feb. webrev: http://cr.openjdk.java.net

Re: Fwd: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly

2012-06-12 Thread Joe Wang
Looks good to me, Lance. Best, Joe On 6/12/2012 1:21 PM, Lance Andersen - Oracle wrote: Still looking for a reviewer on this. All SQE, unit tests, JCK and TCK tests pass. Best Lance Begin forwarded message: From: Lance Andersen - Oraclelance.ander...@oracle.com Date: May 25, 2012

Re: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException

2012-06-13 Thread Joe Wang
Hi Lance, The changes look good to me. Joe On 6/13/2012 4:09 AM, Paul Sandoz wrote: On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote: Hi Paul, Thank you for taking the time to review the code. I made the change you suggested below

RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-21 Thread Joe Wang
Hi, This is a patch to replace the manual process in the 3rd step of the JAXP implementation resolution mechanism with ServiceLoader. Please see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for more details about the issue. Note that FactoryFinder is duplicated for each JAXP

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-21 Thread Joe Wang
jaxp tck passed. Joe On 6/21/2012 12:55 AM, Joe Wang wrote: Hi, This is a patch to replace the manual process in the 3rd step of the JAXP implementation resolution mechanism with ServiceLoader. Please see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for more details about

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-21 Thread Joe Wang
was that .load returns an instance. There's a situation where a static method or constructor with a parameter instead of the default constructor may be called to initiate the provider. -Joe Paul. On Jun 21, 2012, at 9:55 AM, Joe Wang wrote: Hi, This is a patch to replace the manual

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-21 Thread Joe Wang
On 6/21/2012 5:44 AM, Alan Bateman wrote: On 21/06/2012 08:55, Joe Wang wrote: : webrev: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ It's great to get this work started. The javadoc changes look okay to me and fine for this change. However there are a few areas that could

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-21 Thread Joe Wang
On 6/21/2012 11:04 AM, Alan Bateman wrote: On 21/06/2012 18:34, Joe Wang wrote: : When iterating over the service instances you are catching ConfigurationError 264 ServiceLoader loader = ServiceLoader.load(serviceClass, cl); 265 final Iterator providers

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-21 Thread Joe Wang
On 6/21/2012 2:00 PM, Alan Bateman wrote: On 21/06/2012 19:02, Joe Wang wrote: : For the class loader, as discussed with Paul, since the ServiceLoader does so much, we may be able to skip the 'using different classloader' part, that is, simply calling load without classloader

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-22 Thread Joe Wang
On 6/22/2012 2:39 AM, Alan Bateman wrote: On 21/06/2012 22:53, Joe Wang wrote: : We're not considering this change for jdk7 or older, i.e. I haven't thought about fixing 6975142. For jdk8, it seems we have to live with the way it is in (2), a seemly incompatible behavior in backward

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-25 Thread Joe Wang
it in as it stands now and work out another patch for the duplicated classes once we have a solution. New webrev: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ Thanks, Joe On 6/22/2012 10:24 AM, Joe Wang wrote: On 6/22/2012 2:39 AM, Alan Bateman wrote: On 21/06/2012 22:53, Joe Wang wrote

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-25 Thread Joe Wang
On 6/25/2012 5:14 AM, Alan Bateman wrote: On 25/06/2012 08:38, Joe Wang wrote: Hi all, Thanks for all the comments! I've updated the patch for the following recommended changes: 1. ServiceConfigurationError instead of ConfigurationError 2. Use factory class, class.forName section removed 3

Re: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

2012-06-25 Thread Joe Wang
().getContextClassLoader(). Good catch, yes we do! We're virtually delegating those calls to the ServiceLoader that could be blocked when security is on. Joe Paul. On Jun 25, 2012, at 9:38 AM, Joe Wang wrote: Hi all, Thanks for all the comments! I've updated the patch for the following

Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException

2012-06-26 Thread Joe Wang
escapeNonUSAscii is slightly misleading, it should be really called something like escapeCharactersInUriString. Note that '[' and ']' are not valid URI characters outside of an IPv6 encoded address. Paul. On Jun 23, 2012, at 1:09 AM, Joe Wang wrote: Hi, This is a patch to fix the IPv6 issue

Re: RFR 8139056: Add convenience methods to Statement.java

2015-10-20 Thread Joe Wang
Hi Lance, The change looks good. Noticed two minor things in StatementTests.java: A typo at 52 * Validate a NullPointerException is thrown is the string passed to. The 2nd "is" was meant to be "if" For test03, param "expected" may be not needed. Best, Joe On 10/20/2015 1:19 PM,

  1   2   3   4   5   6   7   8   9   >