This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Security provider fallback
- From: Tom Tromey <tromey at redhat dot com>
- To: Mark Wielaard <mark at klomp dot org>
- Cc: java-patches at gcc dot gnu dot org
- Date: 05 Mar 2003 19:30:53 -0700
- Subject: Re: Security provider fallback
- References: <1046629565.19771.561.camel@elsschot>
- Reply-to: tromey at redhat dot com
>>>>> "Mark" == Mark Wielaard <mark at klomp dot org> writes:
Mark> The following prints a warning when non of the security provider files
Mark> could be read or non of them contain any valid entries and falls back to
Mark> the standard Gnu provider. If the security provider files do exist, but
Mark> just don't contain any provider the user gets what was asked for.
Mark> This helps in situations where the security file is missing or not
Mark> correctly installed (which seems to happen often with VMs). It also
Mark> fixes a couple of Mauve failures that would happen if you did a make
Mark> check without a make install first (and no old installation was
Mark> available) like most autobuilders do.
My first inclination is not to do this. The class library is a
library; printing to stderr like this is a bit unfriendly. It seems
to violate the bounds of what a library ought to do.
I'd like to know more about the situation that lead up to this patch.
I assume you ran into some trouble? I don't like to say "no", but at
least in this case I need to be convinced.
Mark> WARNING: could not properly read security provider files:
Mark> file:///usr/local/gcc34/lib/security/libgcj.security
Mark> file:///usr/local/gcc34/lib/security/classpath.security
Mark> Falling back to standard GNU security provider
The wording is fine.
Tom