RFR 7191662: JCE providers should be located via ServiceLoader,

[Chris Hegarty]

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.
>>
>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.00/make/gensrc/Gensrc-java.naming.gmk.html
>>
>>
>> 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.

-Chris.


> /Erik
>>
>>> On May 21, 2015, at 3:03 PM, Valerie Peng <valerie.peng at oracle.com>
>>> wrote:
>>>
>>> Mandy,
>>>
>>> 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.
>>>>
>>>> src/jdk.crypto.ucrypto/solaris/classes/META-INF/services/java.security.Provider.html
>>>>
>>>> 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) $^ > $@
>> endef
>>
>>
>>> 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
>> Mandy
>