commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [lang] Running lang under a security manager and LANG-744
Date Sat, 03 Sep 2011 15:10:31 GMT
On 3 September 2011 05:37, Henri Yandell <> wrote:
> I'm less concerned with the 115 errors, unless they're all as grievous
> as the StringUtils one - ie) the method causing trouble is not the
> only one broken.
> If the error happened when calling stripAccents, that would be
> workable; but having all of StringUtils unavailable is very painful.
> One option would be to move the code out of the static initializer and
> make it lazy when stripAccents is first called - leading to only
> callers of stripAccents when the JDK 6 class is unavailable to suffer
> pain.

I thought we'd already fixed that by catching the extra Exception?

I already suggested localising the error display to the stripAccents method.

> I thought we could simplify things by simply making the java6Available
> flag be a real test for Java 6, but Android seems very weird there. Is
> Android going to force us to stay on the EOL Java 5, or is it Java 6
> compatible? IIUC it reports itself as 0.9, which we've declared as
> equivalent to JDK 1.5.

Are you sure that is the issue?
Surely the Android problem is that we check for the sun class but
don't handle all possible errors?
So the class does not load; it cannot use the Java6 method even if it exists.

> That relates to another (simple) solution - move to Java 6 :)

Or capture Exception for both the java6 and sun tests; report the
exception(s) if neither is available when required.

The static block would then always complete; only methods using the
optional code would be affected.

> Hen
> On Thu, Sep 1, 2011 at 5:20 PM, Gary Gregory <> wrote:
>> WRT LANG-744 "StringUtils throws on
>> Google App Engine"
>> Well, I've ruminated, pondered and experimented.
>> Running all unit tests with a security managers results in:
>> Tests run: 2046, Failures: 2, Errors: 115, Skipped: 0
>> Clearly, we need a good overall solution to avoid 117 new Jiras (an
>> exaggeration I know.)
>> I've created a JAAS policy file to grant just enough permissions to run the
>> unit tests in {{src/test/resource/java.policy}}
>> The file contains instructions for using it with JAAS.
>> What this shows is that we should either:
>> # Run all unit tests a second time with JAAS enabled, or
>> # Run all unit tests with JAAS enabled, always
>> We should our solution as a pattern for other Commons component.
>> Specifically for StringUtils, should we have a SunStringUtils? This would
>> let you know that you are depending on com.sun code.
>> Thoughts?
>> --
>> Thank you,
>> Gary
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message