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.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
