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 system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces. New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException. Existing tests: mainly replaced CatalogUriResolver with CatalogResolver. JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/ Thanks, Joe
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 CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces.
New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException.
Existing tests: mainly replaced CatalogUriResolver with CatalogResolver.
JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/
Thanks, Joe
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 CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces.
New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException.
Existing tests: mainly replaced CatalogUriResolver with CatalogResolver.
JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/
Thanks, Joe
+1
On Aug 26, 2016, at 1:06 PM, Joe Wang <huizhe.wang@oracle.com> 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 CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces.
New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException.
Existing tests: mainly replaced CatalogUriResolver with CatalogResolver.
JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/
Thanks, Joe
<http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen@oracle.com <mailto:Lance.Andersen@oracle.com>
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 <huizhe.wang@oracle.com <mailto:huizhe.wang@oracle.com>> 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 CatalogResolver is usable for all JDK XML processors. As with the existing resolver interfaces, the change makes it no distinction between system identifiers and URIs, which would make it easier for users to create catalogs (without worrying about when and why to use what type of catalog entries). The implementation is almost identical for all JDK XML resolver interfaces.
New tests: added to CatalogTest.java to cover URIResolver (Transform), XMLResolver (StAX) and LSResourceResolver (Validation). new CatalogSupport5.java is added to cover error handling. When there is no match found, a processor shall return with the specified checked exception rather than CatalogException.
Existing tests: mainly replaced CatalogUriResolver with CatalogResolver.
JBS: https://bugs.openjdk.java.net/browse/JDK-8163232 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8163232/webrev/ <http://cr.openjdk.java.net/%7Ejoehw/jdk9/8163232/webrev/>
Thanks, Joe
<http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen@oracle.com <mailto:Lance.Andersen@oracle.com>
participants (3)
-
Daniel Fuchs
-
Joe Wang
-
Lance Andersen