Re: [lang] Running lang under a security manager and LANG-744
I'm working on a fix now. Have a look when it is committed to see if
it can be improved.
On 6 September 2011 15:48, Paul Benedict wrote:
> Make the sun class be loaded dynamically -- not statically -- and if
> it is not present, just throw an UnsupportedOperationException? I
> think that would solve Android's problem.
>
> On Tue, Sep 6, 2011 at 8:36 AM, sebb wrote:
>> On 6 September 2011 05:44, David Karlsen wrote:
>>> I think tying to sun classes is a bad idea.
>>
>> Yes, which is why the code checks to see if the class is present.
>>
>> If the Java 6 method is available, then it uses that, otherwise it
>> checks for the Sun method.
>> If neither is available, then the code throws an
>> UnsupportedOperationException in the stripAccents() method.
>>
>>> Den 6. sep. 2011 05:54 skrev "sebb" følgende:
On 6 September 2011 04:33, Henri Yandell wrote:
> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>> 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.
>
> Sorry - not operating at 100% last week.
>
>>> 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.
>
> I'm very confused between Android and GAE :)
>
>>> 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.
>
> I like this. Capture the exception in the static initializer and then
> throw a new runtime exception in stripAccents that refers to said
> exception. Perhaps an IllegalStateException("blah", originalException)
> ?
It currently throws UnsupportedOperationException; I think we should
keep that as it's more accurate.
There will always be two Exceptions at that point (otherwise we must
have Java 6 or Sun).
We know we need to report the Sun Exception - is there any need to
report the Java 6 exception?
i.e. could we be running on Java 6 but still get an Exception?
For completeness (and debugging) we should probably report both.
Perhaps we could nest the exceptions.
> Hen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.
On Tue, Sep 6, 2011 at 8:36 AM, sebb wrote:
> On 6 September 2011 05:44, David Karlsen wrote:
>> I think tying to sun classes is a bad idea.
>
> Yes, which is why the code checks to see if the class is present.
>
> If the Java 6 method is available, then it uses that, otherwise it
> checks for the Sun method.
> If neither is available, then the code throws an
> UnsupportedOperationException in the stripAccents() method.
>
>> Den 6. sep. 2011 05:54 skrev "sebb" følgende:
>>> On 6 September 2011 04:33, Henri Yandell wrote:
On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
> 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.
Sorry - not operating at 100% last week.
>> 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.
I'm very confused between Android and GAE :)
>> 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.
I like this. Capture the exception in the static initializer and then
throw a new runtime exception in stripAccents that refers to said
exception. Perhaps an IllegalStateException("blah", originalException)
?
>>>
>>> It currently throws UnsupportedOperationException; I think we should
>>> keep that as it's more accurate.
>>>
>>> There will always be two Exceptions at that point (otherwise we must
>>> have Java 6 or Sun).
>>> We know we need to report the Sun Exception - is there any need to
>>> report the Java 6 exception?
>>> i.e. could we be running on Java 6 but still get an Exception?
>>>
>>> For completeness (and debugging) we should probably report both.
>>>
>>> Perhaps we could nest the exceptions.
>>>
Hen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On 6 September 2011 05:44, David Karlsen wrote:
> I think tying to sun classes is a bad idea.
Yes, which is why the code checks to see if the class is present.
If the Java 6 method is available, then it uses that, otherwise it
checks for the Sun method.
If neither is available, then the code throws an
UnsupportedOperationException in the stripAccents() method.
> Den 6. sep. 2011 05:54 skrev "sebb" følgende:
>> On 6 September 2011 04:33, Henri Yandell wrote:
>>> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
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.
>>>
>>> Sorry - not operating at 100% last week.
>>>
> 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.
>>>
>>> I'm very confused between Android and GAE :)
>>>
> 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.
>>>
>>> I like this. Capture the exception in the static initializer and then
>>> throw a new runtime exception in stripAccents that refers to said
>>> exception. Perhaps an IllegalStateException("blah", originalException)
>>> ?
>>
>> It currently throws UnsupportedOperationException; I think we should
>> keep that as it's more accurate.
>>
>> There will always be two Exceptions at that point (otherwise we must
>> have Java 6 or Sun).
>> We know we need to report the Sun Exception - is there any need to
>> report the Java 6 exception?
>> i.e. could we be running on Java 6 but still get an Exception?
>>
>> For completeness (and debugging) we should probably report both.
>>
>> Perhaps we could nest the exceptions.
>>
>>> Hen
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On Sep 5, 2011, at 23:34, Henri Yandell wrote:
> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>> 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.
>
> Sorry - not operating at 100% last week.
>
>>> 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.
>
> I'm very confused between Android and GAE :)
>
>>> 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.
>
> I like this. Capture the exception in the static initializer and then
> throw a new runtime exception in stripAccents that refers to said
> exception. Perhaps an IllegalStateException("blah", originalException)
> ?
Sounds less painful than the current code. Give it a try.
Gary
>
> Hen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
I think tying to sun classes is a bad idea.
Den 6. sep. 2011 05:54 skrev "sebb" følgende:
> On 6 September 2011 04:33, Henri Yandell wrote:
>> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>>> 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.
>>
>> Sorry - not operating at 100% last week.
>>
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.
>>
>> I'm very confused between Android and GAE :)
>>
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.
>>
>> I like this. Capture the exception in the static initializer and then
>> throw a new runtime exception in stripAccents that refers to said
>> exception. Perhaps an IllegalStateException("blah", originalException)
>> ?
>
> It currently throws UnsupportedOperationException; I think we should
> keep that as it's more accurate.
>
> There will always be two Exceptions at that point (otherwise we must
> have Java 6 or Sun).
> We know we need to report the Sun Exception - is there any need to
> report the Java 6 exception?
> i.e. could we be running on Java 6 but still get an Exception?
>
> For completeness (and debugging) we should probably report both.
>
> Perhaps we could nest the exceptions.
>
>> Hen
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
Re: [lang] Running lang under a security manager and LANG-744
On 6 September 2011 04:33, Henri Yandell wrote:
> On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
>> 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.
>
> Sorry - not operating at 100% last week.
>
>>> 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.
>
> I'm very confused between Android and GAE :)
>
>>> 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.
>
> I like this. Capture the exception in the static initializer and then
> throw a new runtime exception in stripAccents that refers to said
> exception. Perhaps an IllegalStateException("blah", originalException)
> ?
It currently throws UnsupportedOperationException; I think we should
keep that as it's more accurate.
There will always be two Exceptions at that point (otherwise we must
have Java 6 or Sun).
We know we need to report the Sun Exception - is there any need to
report the Java 6 exception?
i.e. could we be running on Java 6 but still get an Exception?
For completeness (and debugging) we should probably report both.
Perhaps we could nest the exceptions.
> Hen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On Sat, Sep 3, 2011 at 8:10 AM, sebb wrote:
> 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.
Sorry - not operating at 100% last week.
>> 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.
I'm very confused between Android and GAE :)
>> 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.
I like this. Capture the exception in the static initializer and then
throw a new runtime exception in stripAccents that refers to said
exception. Perhaps an IllegalStateException("blah", originalException)
?
Hen
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
I am going to play with surefire executions and see how that goes.
Gary
On Sep 3, 2011, at 19:37, Mark Struberg wrote:
> 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
>> To: Commons Developers List
>> 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 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
>> 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-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
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
> To: Commons Developers List
> 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 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
> 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-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
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 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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
To see the security manager in action you just need to comment out one line of code in the POM. Ideally I would like to be able to run the tests twice, once with a d without the sec man. Good luck to me trying to figure out how to do this in maven :( ant would be easy ;) Ideas? Gary On Sep 3, 2011, at 1:20, Phil Steitz wrote: > On 9/2/11 4:06 AM, Gary Gregory wrote: >> On Sep 2, 2011, at 1:21, Stephen Colebourne wrote: >> >>> On 2 September 2011 01:20, Gary Gregory wrote: Specifically for StringUtils, should we have a SunStringUtils? This would let you know that you are depending on com.sun code. >>> I really don't like that idea! >>> >>> Generally, it is non-Sun JVMs including Android that are the problem. >>> Lets just do the best we can on those. >>> >> But that is different that the actual issue of running under a >> security manager. > > Right. This thread is talking about two different issues. What > actually caused the exception reported in the ticket is GAE > disallowing the privileged action. GAE does not allow all kinds of > stuff. You can't even load JCE providers. The other form of > "crippled Java" is missing classes or APIs, which you run into with > Android. I think your idea of testing with security managers is a > good one so that we can see and document what is going to blow up > with that kind of crippling. Supporting Android or other crippled > environments is harder. In both cases it comes down to volunteer > resources to a) do all the testing b) document the failures and c) > propose (and maybe get the community to agree on) workarounds. > Personally, none of these activities are likely to make it to the > top of my always-too-long list of things to work on here, but I > won't complain and will apply patches that do no harm while making > more things work for more users. > > Phil >> >> Gary >> >>> Stephen >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
This might be a bit OT, but is there a cardinal way to create code with and without doPrivileged code? I mean something like pre-processing or a replacement with sed. In OpenWebBeans we introduced a SecurityService SPI with 2 implementations: A standard one without doPrivileged and an enforcing one. The ct of the enforcing one makes sure that it can only get created from within OWBs core so it cannot get tricked for non intended usage. In our case it was not the problem with GAE but simply the fact that the SecurityManager only gets used pretty rarely and sucks a lot of the performance. Since OWB as DI container heavily uses interceptors, we got way more than 1 million temporary objects/s and the performance drops by 25% when using doPrivileged. LieGrue, strub - Original Message - > From: Phil Steitz > To: Commons Developers List > Cc: > Sent: Saturday, September 3, 2011 7:19 AM > Subject: Re: [lang] Running lang under a security manager and LANG-744 > > On 9/2/11 4:06 AM, Gary Gregory wrote: >> On Sep 2, 2011, at 1:21, Stephen Colebourne > wrote: >> >>> On 2 September 2011 01:20, Gary Gregory > wrote: >>>> Specifically for StringUtils, should we have a SunStringUtils? This > would >>>> let you know that you are depending on com.sun code. >>> I really don't like that idea! >>> >>> Generally, it is non-Sun JVMs including Android that are the problem. >>> Lets just do the best we can on those. >>> >> But that is different that the actual issue of running under a >> security manager. > > Right. This thread is talking about two different issues. What > actually caused the exception reported in the ticket is GAE > disallowing the privileged action. GAE does not allow all kinds of > stuff. You can't even load JCE providers. The other form of > "crippled Java" is missing classes or APIs, which you run into with > Android. I think your idea of testing with security managers is a > good one so that we can see and document what is going to blow up > with that kind of crippling. Supporting Android or other crippled > environments is harder. In both cases it comes down to volunteer > resources to a) do all the testing b) document the failures and c) > propose (and maybe get the community to agree on) workarounds. > Personally, none of these activities are likely to make it to the > top of my always-too-long list of things to work on here, but I > won't complain and will apply patches that do no harm while making > more things work for more users. > > Phil >> >> Gary >> >>> Stephen >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On 9/2/11 4:06 AM, Gary Gregory wrote: > On Sep 2, 2011, at 1:21, Stephen Colebourne wrote: > >> On 2 September 2011 01:20, Gary Gregory wrote: >>> Specifically for StringUtils, should we have a SunStringUtils? This would >>> let you know that you are depending on com.sun code. >> I really don't like that idea! >> >> Generally, it is non-Sun JVMs including Android that are the problem. >> Lets just do the best we can on those. >> > But that is different that the actual issue of running under a > security manager. Right. This thread is talking about two different issues. What actually caused the exception reported in the ticket is GAE disallowing the privileged action. GAE does not allow all kinds of stuff. You can't even load JCE providers. The other form of "crippled Java" is missing classes or APIs, which you run into with Android. I think your idea of testing with security managers is a good one so that we can see and document what is going to blow up with that kind of crippling. Supporting Android or other crippled environments is harder. In both cases it comes down to volunteer resources to a) do all the testing b) document the failures and c) propose (and maybe get the community to agree on) workarounds. Personally, none of these activities are likely to make it to the top of my always-too-long list of things to work on here, but I won't complain and will apply patches that do no harm while making more things work for more users. Phil > > Gary > >> Stephen >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
Bad first paragraph.
ie) the method causing trouble is not the one the user wants to use.
For example - they want to use StringUtils.chomp, and the
implementation of stripAccents is blocking them.
Sorry for the double post,
Hen
On Fri, Sep 2, 2011 at 9:37 PM, 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 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.
>
> That relates to another (simple) solution - move to Java 6 :)
>
> Hen
>
> On Thu, Sep 1, 2011 at 5:20 PM, Gary Gregory 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
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 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.
That relates to another (simple) solution - move to Java 6 :)
Hen
On Thu, Sep 1, 2011 at 5:20 PM, Gary Gregory 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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On 2 September 2011 12:06, Gary Gregory wrote: > On Sep 2, 2011, at 1:21, Stephen Colebourne wrote: > >> On 2 September 2011 01:20, Gary Gregory wrote: >>> Specifically for StringUtils, should we have a SunStringUtils? This would >>> let you know that you are depending on com.sun code. >> >> I really don't like that idea! >> >> Generally, it is non-Sun JVMs including Android that are the problem. >> Lets just do the best we can on those. >> > But that is different that the actual issue of running under a > security manager. 1) I don't think we should create a Sun-specific class. 2) However, we should ensure that the code behaves sensibly if the Sun class is not available for whatever reason. So we should ensure that we can test for that; ideally without needing to edit the POM. For components that explicitly use sun classes, we need to be able to test both with and without Sun classes. This should be achievable with a profile, but that is not ideal. For components that rely on sun classes it would be best if the tests were always run with both settings. Then CI servers such as Gump and Continuum and Jenkins would be better placed to warn of issues. > Gary > >> Stephen >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On Sep 2, 2011, at 1:21, Stephen Colebourne wrote: > On 2 September 2011 01:20, Gary Gregory wrote: >> Specifically for StringUtils, should we have a SunStringUtils? This would >> let you know that you are depending on com.sun code. > > I really don't like that idea! > > Generally, it is non-Sun JVMs including Android that are the problem. > Lets just do the best we can on those. > But that is different that the actual issue of running under a security manager. Gary > Stephen > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] Running lang under a security manager and LANG-744
On 2 September 2011 01:20, Gary Gregory wrote: > Specifically for StringUtils, should we have a SunStringUtils? This would > let you know that you are depending on com.sun code. I really don't like that idea! Generally, it is non-Sun JVMs including Android that are the problem. Lets just do the best we can on those. Stephen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] Running lang under a security manager and LANG-744
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
