RFR 7191662: JCE providers should be located via ServiceLoader,
chris.hegarty at oracle.com
Fri May 22 12:55:26 UTC 2015
On 22/05/15 07:58, Erik Joelsson wrote:
> On 2015-05-22 02:46, Mandy Chung wrote:
>> I’m including build-dev and we need to ask for Erik and Magnus advice
>> what’s the best way to work around this.
>> Erik, Magnus,
>> Security providers now become service providers. They are
>> provided from 11 different modules, 3 of them are os-specific. The
>> current image builder doesn’t merge duplicate resources and we
>> currently work around it in the build doing the merge as it’s
>> temporary until the module system is moving further.
>> Gensrc-jdk.jdi.gmk is the example.
>> Valerie has a patch attempting to concatenate them and it turns out
>> that it might not be straight forward I have thought.
>> As we can’t say which one image builder will pick, it needs to copy
>> gensrc (merged version) to all
>> modules/$MODULE/META-INF/services/java.security.Provider config files.
>> I wonder if it’s quicker to hack ImageBuilder to special case the
>> service config file and merge them.
>> Any thought?
> I could certainly make this work in the makefile, but it is getting a
> bit tedious to keep these hacks going there. How hard would it be to
> change the ImageBuilder, which is just a temporary solution anyway, to
> identify and merge all service provider files with the same name that it
> finds? With that solution, the makefiles do not need to change as much
> when the module system is introduced and taking care of this properly.
I think it could be done either way.
>>> On May 21, 2015, at 3:03 PM, Valerie Peng <valerie.peng at oracle.com>
>>> Please find comments in line.
>>> On 5/20/2015 10:39 PM, Mandy Chung wrote:
>>>> A quick comment on the META-INF/services config files and the
>>>> makefile. Merging the service config files is temporary until the
>>>> module system is moving further along.
>>>> and other os-specific service configuration:
>>>> 1 #[solaris]com.oracle.security.ucrypto.UcryptoProvider
>>>> - why is this commented out? Does the makefile uncomment it? It
>>>> should be simple
>>>> concatenation with
>>> In an example that I found through another makefile, it would
>>> uncomment the entry start with "#[OS]" (and process/remove this
>>> prefix) when the OS matches. We need OS-specific file processing when
>>> concatenate these files.
>> Ah… that’s from Gensrc-jdk.jdi.gmk. The service config file contains
>> a mixture of cross-neutral and os-specific providers. That’s not the
>> example to copy.
>> define process-provider
>> $(MKDIR) -p $(@D)
>> $(CAT) $^ > $@
>>> What decides if it's appropriate or not? These are not just crypto
>>> providers that we are defining here, but all classes which extend
>>> from java.security.Provider. I recall using jdk.crypto.ec as the
>>> gensrc module as you suggested initially. But when testing it, it
>>> doesn't seem to work as expected. I ended up using java.naming as
>>> that's the one ended up in the final image instead of the
>>> concatenated one under jdk.crypto.ec. Could there be some alphabetic
>>> ordering when processing/building these modules?
>>> Well, since this is really a hack and only temporary, does it really
>>> matter whether it's under java.naming or jdk.crypto.ec? Both contains
>>> providers for the java.security provider list. The key thing is that
>>> the resulting image works
More information about the security-dev