I've updated to:
* @run main/othervm CryptoPolicyFallback
I'll have a new review out shortly.
Brad
On 11/23/2016 2:29 AM, Wang Weijun wrote:
Hi Brad
I think I found a problem with the test. Before you set your local
java.security file, the system java.security file was already read (in
jtr
Hi Brad
I think I found a problem with the test. Before you set your local
java.security file, the system java.security file was already read (in
jtreg initialization) and limited was picked up. In fact, I modified the
java.security file of my own JDK to unlimited and the test fails.
This se
On 17/11/2016 17:46, Bradford Wetmore wrote:
On 11/17/2016 7:19 AM, Seán Coffey wrote:
The /policy= jtreg tag was also another possible solution.
That's a policy file, not a java.security file.
Ah, of course. Wasn't thinking right.
regards,
Sean.
SeanM pointed out that we could do a:
On 11/17/2016 7:19 AM, Seán Coffey wrote:
The /policy= jtreg tag was also another possible solution.
That's a policy file, not a java.security file.
SeanM pointed out that we could do a:
@main -Djava.security.properties=xxx
but that would require storing a snapshot of java.security. I
Looks good to me. I didn't know you could pass a plain file 'name' to
java.security.properties. The docs indicate that a URL is required but
the jdk code suggests your approach will work.
The /policy= jtreg tag was also another possible solution.
regards,
Sean.
On 17/11/2016 01:33, Bradford
> On Nov 17, 2016, at 9:33 AM, Bradford Wetmore
> wrote:
>
>try (PrintWriter out = new PrintWriter(FILENAME)) {
>Files.lines(path)
>.filter(x -> !x.trim().startsWith("crypto.policy"))
>.forEach(out::println);
>}
Not very sure.
> http://cr.openjdk.java.net/~wetmore/8169335/webrev.02
Looks fine to me.
BTW, I was just wondering, do you want to allow empty security property
(cryptoPolicyProperty.length() is 0) as well?
Xuelei
On 11/17/2016 9:33 AM, Bradford Wetmore wrote:
On 11/16/2016 4:14 PM, Wang Weijun wrote:
On 11/16/2016 4:14 PM, Wang Weijun wrote:
On Nov 17, 2016, at 6:10 AM, Bradford Wetmore
wrote:
Current iteration:
http://cr.openjdk.java.net/~wetmore/8169335/webrev.01
Changes:
1. Using Debug "jca" instead of "policy"
2. Using debug.println (System.err), as the other jca calls ar
> On Nov 17, 2016, at 6:10 AM, Bradford Wetmore
> wrote:
>
>
> Current iteration:
>
>http://cr.openjdk.java.net/~wetmore/8169335/webrev.01
>
> Changes:
>
> 1. Using Debug "jca" instead of "policy"
>
> 2. Using debug.println (System.err), as the other jca calls are also using
> it.
Current iteration:
http://cr.openjdk.java.net/~wetmore/8169335/webrev.01
Changes:
1. Using Debug "jca" instead of "policy"
2. Using debug.println (System.err), as the other jca calls are also
using it.
3. Added regression test. Strips out any crypto.policy entry to create
a new fi
In the recent jdk8u-dev edits of this file for 8157561, we introduced a
debug field based on this key :
Debug.getInstance("jca", "Cipher");
Can we continue to use 'jca' to be consistent for people upgrading ?
for the testcase, I guess you can edit
test/javax/crypto/CryptoPermission/TestUnlimi
Never noticed that before! We have NOT been consistent in whether we use:
System.out.println()
or
debug.println()
I knew SeanC wants to rework the JCA/JCE/Security debugging output in
another project, so I will remove the prefix for now. Thanks for
catching it.
I will also add a si
You create a debug field with a prefix string and then check both debug != null
and Debug.isOn("policy") and then use System.out.println to print the message.
Something must be useless.
--Max
> On Nov 16, 2016, at 3:31 AM, Bradford Wetmore
> wrote:
>
> Simple codereview:
>
>http://cr.op
Simple codereview:
http://cr.openjdk.java.net/~wetmore/8169335/webrev.00
The "crypto.policy" Security property is normally defined/configured in
the java.security file at build time. (e.g. "limited" or "unlimited")
Rather than currently failing catastrophically if this value doesn't
exis
14 matches
Mail list logo
