commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [lang] Running lang under a security manager and LANG-744
Date Sat, 03 Sep 2011 23:37:03 GMT
Create a test.jar as attached artifact. Then create a sub module where you dependency:unpack
this test-jar and run the tests in your new configuration. This can also be done via the maven-invoker-plugin.

LieGrue,
strub


----- Original Message -----
> From: sebb <sebbaz@gmail.com>
> To: Commons Developers List <dev@commons.apache.org>
> Cc: 
> Sent: Saturday, September 3, 2011 5:10 PM
> Subject: Re: [lang] Running lang under a security manager and LANG-744
> 
> On 3 September 2011 05:37, Henri Yandell <flamefew@gmail.com> 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 <garydgregory@gmail.com> 
> wrote:
>>>  WRT LANG-744 "StringUtils throws 
> java.security.AccessControlException 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
>>> 
>>>  http://garygregory.wordpress.com/
>>>  http://garygregory.com/
>>>  http://people.apache.org/~ggregory/
>>>  http://twitter.com/GaryGregory
>>> 
>> 
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>  For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message