Re: RFR: 8186958: Need method to create pre-sized HashMap [v21]
On Thu, 14 Apr 2022 18:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > add `@LastModified: Apr 2022` to DocumentCache Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v20]
On Thu, 14 Apr 2022 18:05:48 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java >> line 3: >> >>> 1: /* >>> 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights >>> reserved. >>> 3: */ >> >> The LastModified tag was missing in this class. Pls use this opportunity to >> add it in the same format as the other classes (CoreDocumentImpl, >> XSAttributeChecker), that is after line 52. Thanks. > > @JoeWang-Java done. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v20]
On Thu, 14 Apr 2022 17:05:39 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > revert changes on ProcessEnvironment src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java line 3: > 1: /* > 2: * Copyright (c) 2015, 2022, Oracle and/or its affiliates. All rights > reserved. > 3: */ The LastModified tag was missing in this class. Pls use this opportunity to add it in the same format as the other classes (CoreDocumentImpl, XSAttributeChecker), that is after line 52. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Thu, 14 Apr 2022 01:13:18 GMT, XenoAmess wrote:
>> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java
>> line 1819:
>>
>>> 1817: Map items;
>>> 1818: LargeContainer(int size) {
>>> 1819: items = HashMap.newHashMap(size*2+1);
>>
>> I'm wondering if we should change this to just `newHashMap(size)` since it
>> looks like this container is intended to hold up to `size` items.
>> @JoeWang-Java ? I suspect the `size*2+1` was a failed attempt at allocating
>> a HashMap of the correct capacity for `size` mappings.
>
>> I suspect the `size*2+1` was a failed attempt at allocating a HashMap of the
>> correct capacity for `size` mappings.
>
> I looked the codes and don't think so..
> If I'm wrong, I'm glad to fix.
Stuart's right, I looked at the code, it's as you said a failed attempt, "size"
would be good. So HashMap.newHashMap(size) would actually be a small
improvement.
It's an interesting impl the way it used HashMap, but it's 20 year code.
-
PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v18]
On Thu, 14 Apr 2022 01:15:05 GMT, XenoAmess wrote: >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java >> line 171: >> >>> 169: _current = 0; >>> 170: _size = size; >>> 171: _references = HashMap.newHashMap(_size); >> >> Not `_size+2` ? > >> Not `_size+2` ? > > I don't have a idea here why he original use the + 2. > Is there any guy more familiar with this code tell me why? > Thanks! size, not size + 2, same situation as size*2+1 below. - PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8186958: Need method to create pre-sized HashMap [v16]
On Wed, 13 Apr 2022 16:29:11 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional > commit since the last revision: > > revert changes in: > src/java.desktop > src/java.management > src/jdk.internal.vm.ci > src/jdk.jfr > src/jdk.management.jfr > src/jdk.management > src/utils/IdealGraphVisualizer Looks good for the changes in java.xml, like Naoto, assuming copyright years and the LastModified tag are updated. I generally prefer for the source level to stay at 8 as the upstream source is maintained at an older JDK level, but these changes seem to be small enough to tolerate. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7928
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Thu, 7 Apr 2022 01:16:32 GMT, Naoto Sato wrote:
>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
>>
>>> 61: Locale.of("it", "IT", "EURO"),
>>> 62: Locale.forLanguageTag("de-AT"),
>>> 63: Locale.forLanguageTag("fr-CH"),
>>
>> Use the new factory? Ok not to change as these are tests and there are too
>> many of them. It's not deprecated anyways.
>
> `Locale.forLanguageTag()` is a preferred way to create a `Locale`, as it
> validates the input language tag, while `Locale.of()` doesn't as well as
> Locale constructors.
Ok, I didn't realize the existing method is preferred over the new method in
creating a Locale. The javadoc does state that it does not make any syntactic
checks. That's good to know.
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote: > This is a follow-on task after deprecating the Locale constructors > (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are > simple replacements to Locale constructors with `Locale.of()` or Locale > constants, such as `Locale.US`. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Thu, 7 Apr 2022 01:16:27 GMT, Naoto Sato wrote:
>> test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
>>
>>> 79:
>>> 80: /**
>>> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
>>
>> Locale.France?
>
> The test code parses the input string (eg. "fr_FR") into 3 elements, `name`,
> `country`, and `variant`, then create a `Locale` using those 3 elements.
> Changing it to `Locale.FRANCE` does not seem right here.
I see.
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `Locale.US`.
test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 63:
> 61: Locale.of("it", "IT", "EURO"),
> 62: Locale.forLanguageTag("de-AT"),
> 63: Locale.forLanguageTag("fr-CH"),
Use the new factory? Ok not to change as these are tests and there are too many
of them. It's not deprecated anyways.
test/jdk/java/text/Format/common/Bug6215962.java line 58:
> 56: check(mf1, mf2, false);
> 57:
> 58: mf1 = new MessageFormat("{0}", Locale.of("ja", "JP"));
Locale.JAPAN?
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `Locale.US`.
test/jdk/java/text/Format/DateFormat/NonGregorianFormatTest.java line 131:
> 129:
> 130: // Tests with the Japanese imperial calendar
> 131: Locale calendarLocale = Locale.of("ja", "JP", "JP");
Locale.JAPAN?
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8283698: Refactor Locale constructors used in src/test
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `Locale.US`.
test/jdk/java/text/Format/DateFormat/DateFormatRoundTripTest.java line 81:
> 79:
> 80: /**
> 81: * Parse a name like "fr_FR" into Locale.of("fr", "FR", "");
Locale.France?
-
PR: https://git.openjdk.java.net/jdk/pull/8130
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10
On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For the bundles in java.xml: For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date. For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header. In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well. - PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8277059: Use blessed modifier order in java.xml
On Fri, 12 Nov 2021 15:06:35 GMT, Magnus Ihse Bursie wrote: > I ran bin/blessed-modifier-order.sh on source code in java.xml and > java.xml.crypto. This scripts verifies that modifiers are in the "blessed" > order, and fixes it otherwise. I have manually checked the changes made by > the script to make sure they are sound. Thanks, Magnus. However, we've discussed the issue for sources from the 3rd party, and we'd like it keep it that way to facilitate any future merges. Refer to JDK-8264019 / https://github.com/openjdk/jdk/pull/3091. - PR: https://git.openjdk.java.net/jdk/pull/6369
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang wrote: >> Please review this implementation of [JEP >> 411](https://openjdk.java.net/jeps/411). >> >> The code change is divided into 3 commits. Please review them one by one. >> >> 1. >> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 >> The essential change for this JEP, including the `@Deprecate` annotations >> and spec change. It also update the default value of the >> `java.security.manager` system property to "disallow", and necessary test >> change following this update. >> 2. >> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 >> Manual changes to several files so that the next commit can be generated >> programatically. >> 3. >> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 >> Automatic changes to other source files to avoid javac warnings on >> deprecation for removal >> >> The 1st and 2nd commits should be reviewed carefully. The 3rd one is >> generated programmatically, see the comment below for more details. If you >> are only interested in a portion of the 3rd commit and would like to review >> it as a separate file, please comment here and I'll generate an individual >> webrev. >> >> Due to the size of this PR, no attempt is made to update copyright years for >> any file to minimize unnecessary merge conflict. >> >> Furthermore, since the default value of `java.security.manager` system >> property is now "disallow", most of the tests calling >> `System.setSecurityManager()` need to launched with >> `-Djava.security.manager=allow`. This is covered in a different PR at >> https://github.com/openjdk/jdk/pull/4071. >> >> Update: the deprecation annotations and javadoc tags, build, compiler, >> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are >> reviewed. Rest are 2d, awt, beans, sound, and swing. > > Weijun Wang has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 11 commits: > > - merge from master > - rename setSecurityManagerDirect to implSetSecurityManager > - default behavior reverted to allow > - move one annotation to new method > - merge from master, two files removed, one needs merge > - keep only one systemProperty tag > - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java > - feedback from Sean, Phil and Alan > - add supresswarnings annotations automatically > - manual change before automatic annotating > - ... and 1 more: > https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48 Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4073
Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote: > Please review this implementation of [JEP > 411](https://openjdk.java.net/jeps/411). > > The code change is divided into 3 commits. Please review them one by one. > > 1. > https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 > The essential change for this JEP, including the `@Deprecate` annotations > and spec change. It also update the default value of the > `java.security.manager` system property to "disallow", and necessary test > change following this update. > 2. > https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 > Manual changes to several files so that the next commit can be generated > programatically. > 3. > https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 > Automatic changes to other source files to avoid javac warnings on > deprecation for removal > > The 1st and 2nd commits should be reviewed carefully. The 3rd one is > generated programmatically, see the comment below for more details. If you > are only interested in a portion of the 3rd commit and would like to review > it as a separate file, please comment here and I'll generate an individual > webrev. > > Due to the size of this PR, no attempt is made to update copyright years for > any file to minimize unnecessary merge conflict. > > Furthermore, since the default value of `java.security.manager` system > property is now "disallow", most of the tests calling > `System.setSecurityManager()` need to launched with > `-Djava.security.manager=allow`. This is covered in a different PR at > https://github.com/openjdk/jdk/pull/4071. java.xml changes look good. Thanks. - Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4073
Re: RFR: 8264208: Console charset API [v6]
On Tue, 13 Apr 2021 19:59:30 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been drafted, and comments are welcome >> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Added comment to System.out/err init. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3419
Re: RFR: 8264208: Console charset API [v4]
On Tue, 13 Apr 2021 18:24:55 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/System.java line 2020: >> >>> 2018: setIn0(new BufferedInputStream(fdIn)); >>> 2019: setOut0(newPrintStream(fdOut, cs)); >>> 2020: setErr0(newPrintStream(fdErr, cs)); >> >> It was getting from sun.stdout.encoding or sun.stderr.encoding. After the >> change, when there is no console, it would be set with >> Charset.defaultCharset(). Would that be an incompatible change? > > Although the code path is different, the logic to determine the encoding is > not changed, as `sun.stdout/err.encoding` are only set if the VM is invoked > from a terminal (in fact, there's a bug where they aren't set even in a > terminal on unix env, which I fixed in this patch) which is the same > condition in which `System.console()` returns the console. And for both > cases, it will default to `Charset.defaultCharset()` if they are not > available. > > Having said that, one regression test started to fail with this > implementation change as follows: > > Exception in thread "main" java.util.ServiceConfigurationError: Locale > provider adapter "CLDR"cannot be instantiated. > at > java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:199) > at > java.base/sun.util.locale.provider.LocaleProviderAdapter.findAdapter(LocaleProviderAdapter.java:287) > at > java.base/sun.util.locale.provider.LocaleProviderAdapter.getAdapter(LocaleProviderAdapter.java:258) > at java.base/java.text.NumberFormat.getInstance(NumberFormat.java:960) > at > java.base/java.text.NumberFormat.getNumberInstance(NumberFormat.java:518) > at java.base/java.util.Scanner.useLocale(Scanner.java:1270) > at java.base/java.util.Scanner.(Scanner.java:543) > at java.base/java.util.Scanner.(Scanner.java:554) > at TestConsole.main(TestConsole.java:54) > Caused by: java.lang.reflect.InvocationTargetException > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:78) > at > java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) > at > java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480) > at > java.base/sun.util.locale.provider.LocaleProviderAdapter.forType(LocaleProviderAdapter.java:188) > ... 8 more > > I haven't looked at it in detail but it seems that calling `System.console()` > in `System.initPhase1()` is not allowed, as the module system is not there > yet. So I reverted the implementation to the original and simply retained the > description in `System.out/err` with a change to `determined by` to > `equivalent to`. Thanks for the explanation and updates. It's a worthwhile exercise to attempt to align things around the new method. A short note above line 2023 to record this might be useful as well (sth. like it's eq to console != null ? console.charset() : Charset.defaultCharset();). No need to create another update if you decide to add the note. - PR: https://git.openjdk.java.net/jdk/pull/3419
Re: RFR: 8264208: Console charset API [v4]
On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been drafted, and comments are welcome >> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reverted PrintStream changes src/java.base/share/classes/java/lang/System.java line 2020: > 2018: setIn0(new BufferedInputStream(fdIn)); > 2019: setOut0(newPrintStream(fdOut, cs)); > 2020: setErr0(newPrintStream(fdErr, cs)); It was getting from sun.stdout.encoding or sun.stderr.encoding. After the change, when there is no console, it would be set with Charset.defaultCharset(). Would that be an incompatible change? - PR: https://git.openjdk.java.net/jdk/pull/3419
Re: RFR: 8264208: Console charset API [v2]
On Fri, 9 Apr 2021 21:06:00 GMT, Naoto Sato wrote: >> Please review the changes for the subject issue. This has been suggested in >> a recent discussion thread for the JEP 400 >> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)]. >> A CSR has also been drafted, and comments are welcome >> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)]. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflected the review comments. Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3419
Re: RFR: 8264208: Console charset API [v2]
On Fri, 9 Apr 2021 21:02:26 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/Console.java line 404:
>>
>>> 402: *
>>> 403: * @return A {@code Charset} object used in this {@code Console}.
>>> 404: * @since 17
>>
>> A couple of minor comments:
>> May replace {@code Charset} with @link;
>> Add "the" to the sentence: The returned charset corresponds to "the" input...
>> @return: javadoc guide suggests "do not capitalize and do not end with a
>> period" when writing a phrase. But I guess for consistency in this class,
>> it's okay to capitalize.
>
> Thanks, Joe. Modified as suggested.
Thanks. Looks good to me.
-
PR: https://git.openjdk.java.net/jdk/pull/3419
Re: RFR: 8264208: Console charset API
On Fri, 9 Apr 2021 16:47:55 GMT, Naoto Sato wrote:
> Please review the changes for the subject issue. This has been suggested in
> a recent discussion thread for the JEP 400
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
> A CSR has also been drafted, and comments are welcome
> [[2](https://bugs.openjdk.java.net/browse/JDK-8264209)].
Marked as reviewed by joehw (Reviewer).
src/java.base/share/classes/java/io/Console.java line 404:
> 402: *
> 403: * @return A {@code Charset} object used in this {@code Console}.
> 404: * @since 17
A couple of minor comments:
May replace {@code Charset} with @link;
Add "the" to the sentence: The returned charset corresponds to "the" input...
@return: javadoc guide suggests "do not capitalize and do not end with a
period" when writing a phrase. But I guess for consistency in this class, it's
okay to capitalize.
-
PR: https://git.openjdk.java.net/jdk/pull/3419
Re: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK 11 that works under Java SE 8, 9 and 10
On 2/14/19, 11:08 AM, Sean Mullan wrote: On 2/13/19 2:20 PM, Open eSignForms wrote: Thanks, Sean. I was able to find the updated test case source code. A preliminary review seems to show worthwhile changes to our code. That is, the namespaces and such seem to make sense as you have them. In particular, the use of: domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig"); and adding this namespace to additional elements we added: String xmlns = "http://uri.etsi.org/01903/v1.1.1#;; seem reasonable and an acceptable workaround for us. I'm not sure if those were oversights from before, but likely were the result of it being based on Oracle/Java example code from Java 6 days... We'll incorporate your namespace changes in our code and test, but this seems like it will work as I was able to confirm that your fixed version seems to run on Java 10 and Java 11. It is interesting that the fixed code, though, generates different output on Java 10 and Java 11. I'm not positive, but it seems that Java 11 adds '' to the end of many lines that aren't present in Java 10's output. This is the ASCII code for a carriage return, encoded in XML. I don't know why that behavior is different in JDK 11. This would be a question for the XML developers. I have copied Joe Wang, to see if he might know. Hi Sean, There hasn't been functional change to that area between JDK 10 and 11 that I'm aware of. If you believe there's a behavior change, or you could isolate the issue down to the java.xml/xml processor, please file a bug. I'll be happy to investigate. Thanks, Joe --Sean Under Java 10, a test run products this result: http://open.esignforms.com/XMLSchema/2011; timestamp="2019-02-13T11:02:30-08:00" type="document">xmlns:dsig="http://www.w3.org/2000/09/xmldsig#; Id="OpenESignForms_Seal">http://www.w3.org/2006/12/xml-c14n11#WithComments"/>Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>Id="Payload_Reference_ID" URI="">Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u xbZSyWE5kQ==URI="#KeyInfo_ID">Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc 2N2jA0WKMQ==URI="#QualifyingProperties_ID">Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr r2YDQVgs5w==URI="#OpenESignForms_Seal_ID">Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs l9YV1hNnEg==izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=Id="KeyInfo_ID">c42c747f-0f03-46a3-8ae8-81fc95464c8fkPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=AQABMIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw ZTJiOWUtYzlkMi00O
