Right, that'd be my expectation as well. Sounds like everything works.
I will change to look at your latest webrev.
Valerie
On 12/8/2015 6:09 AM, Sibabrata Sahoo wrote:
Hi Valerie,
Here is the updated webrev:
http://cr.openjdk.java.net/~ralexander/8130360/webrev.00/
Now the modular behavior for the test works as per expectation through JAKE
build with the following condition.
If the provider jar is available under ModulePath then the "java.security" file
should have the provider configuration entry as ProviderName while in case of ClassPath
the entry should hold the full class name.
Thanks,
Siba
-----Original Message-----
From: Valerie Peng
Sent: Tuesday, December 08, 2015 4:46 AM
To: Sibabrata Sahoo
Cc: Alan Bateman; security-dev@openjdk.java.net; jigsaw-...@openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers
if they are in signed/unsigned modular JARs
Siba,
I have just started to review this webrev and not done yet.
As for your question, the java.security file in OpenJDK9 still uses the
provider class names instead of provider names. Are you talking about the
java.security file in Jigsaw? Which build (OpenJDK or Jigsaw) have you tested
against. I am pretty sure that I tested the 3rd party provider on classpath
setting when I worked on the 7191662 changes.
Supposedly, if the jar files are available on class path, then you should specify its full *class
name* in the java.security file for it to be instantiated. Otherwise, how would it find the class?
Only the classes discovered by ServiceLoader can be identified using the provider name (which is
different from the class name referred above). So, in your scenario, that would be
"provider.TestJCEProvider" instead of "TEST".
If you still run into problems, try enable the java security debug flag and u
should get a good idea why it isn't loaded. Let me know if you still have
questions.
Thanks,
Valerie
On 11/30/2015 6:47 AM, Sibabrata Sahoo wrote:
I would like to know more about this. As far, I can see the "java.security"
provider configuration available with JDK9, it holds provider names instead of provider
class names. In that case how it resolve the fall back?
Thanks,
Siba
-----Original Message-----
From: Alan Bateman
Sent: Monday, November 30, 2015 4:54 PM
To: Sibabrata Sahoo; security-dev@openjdk.java.net;
jigsaw-...@openjdk.java.net
Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security
providers if they are in signed/unsigned modular JARs
On 30/11/2015 11:13, Sibabrata Sahoo wrote:
Here is the updated webrev:
http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/
I have one question:
What should be the behavior when the older version of 3rd party JCE provider jar file(without service
descriptor "META-INF/services/*"& working with<= JDK8) configured by
"java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using
Security.getProvider() to look for the provider?
Currently the scenario fails to find the JCE provider. Is this right behavior?
If it is, then jdk9 is not backward compatible to find the security provider
provided through older jar files from CLASS_PATH.
The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling
back and attempting to load the class name specified via the
security.provider.<N> properties in the java.security file. I'm sure Valerie
can say more about this.
-Alan
