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? > On May 21, 2015, at 3:03 PM, Valerie Peng <valerie.p...@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
