[very much RFC][icedtea-web] fix for [Bug 564] NetX depends on sun.misc.BASE64Encoder

[Jiri Vanek]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=564


Hi!

I took the solving of this bug maybe to widely and complexly. Lets reviewer decide which parts to keep.
The patch is trying to use apache-commons-codec's base64 as replacement for sun-misc's base64 proprietary api. The problem is, that although apach-commons-codec are available  at f13 and higher, they are not avaiable for Rhel5 and not even for Rhel6.
So autotools just check if some alternative base64 provider (currently just the apache ones) is avaiable. If so, marks location of jar and adds it to XBoothClasspath of javaws and plugin - I was surprised that adding it to normal classpath have taken no effect (and javaws was working also when classpath setted in luncher's $CP was empty. => Is this correct or bogus??
Whether to use suns or 'alternative' base64 provider is done in runtime - although I'm delaying all reflection calls as alzy as possible and I'm aware of loosing compile time checking and java have no ifdef, _I'm hesitating if this aproach is safe correct_ . :(
Part of the patch is set of unittests which are testing the base64 providers factory and functionality and one reproducer which is checking if build-time selected provider is really used.

I have also kept CHECK_FOR_CLASS sun.misc.BASE64Encoder, but made it just optional. (Then I have added test for alternative apache implementation and added rule that at least one of this two must be available).

Well I know that it is too much code (caused by not100% apache codec availability,  even when ignoring tests) and so I'm thinking wheather really isn't better to add our own nearly copy-pasted-from-somewhere implementation...

Thanx for review, J.

Changelog:


2011-10-07  Jiri Vanek <jvanek at redhat.com>

	* Makefile.am:LAUNCHER_BOOTCLASSPATH and PLUGIN_BOOTCLASSPATH and RUNTIME (especially for junit tests's classpath ) now including also $(BASE64_JAR)
	* a/acinclude.m4: IT_CHECK_FOR_CLASS now accept optional fourth parameter 'w. If this parameter is inlcuded, then not finidng class is just warning insead of error,
	IT_CHECK_FOR_CLASS(SUN_MISC_BASE64ENCODER is now just optional (used 'w' option)
	IT_FIND_OPTIONAL_JAR([base64provider], BASE64,[/usr/share/java/apache-commons-codec.jar]) is added
	added rule, that at least one of sun or alternative base64 provider msut be included
	* netx/net/sourceforge/jnlp/security/CertificateUtils.java: removed import of import sun.misc.BASE64Encoder, added  geting of encoder from net.sourceforge.jnlp.util.BASE64EncoderFactory;
	* netx/net/sourceforge/jnlp/util/BASE64Encoder.java: new file, interface for gathering different base64 providers
	* netx/net/sourceforge/jnlp/util/BASE64EncoderFactory.java: new file, taking care of selecting base64 provider
	* tests/jnlp_tests/signed/CheckBase64Providers/resources/CheckBase64Providers.jnlp:
	* tests/jnlp_tests/signed/CheckBase64Providers/srcs/CheckBase64Providers.java:
	* tests/jnlp_tests/signed/CheckBase64Providers/testcases/CheckBase64ProvidersTest.java:  - reproducer for checking if setted base64 provider is really used
	* tests/netx/unit/net/sourceforge/jnlp/Base64EncodersTests.java: unit test upon BASE64EncoderFactory and individual BASE64Encoders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dif_Add2.diff
Type: text/x-patch
Size: 35299 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20111007/5841bb87/dif_Add2.diff