Re: [lang] Running lang under a security manager and LANG-744
On Sep 5, 2011, at 23:34, Henri Yandell flame...@gmail.com wrote: On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
On 6 September 2011 05:44, David Karlsen davidkarl...@gmail.com 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 seb...@gmail.com følgende: On 6 September 2011 04:33, Henri Yandell flame...@gmail.com wrote: On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
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 seb...@gmail.com wrote: On 6 September 2011 05:44, David Karlsen davidkarl...@gmail.com 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 seb...@gmail.com følgende: On 6 September 2011 04:33, Henri Yandell flame...@gmail.com wrote: On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
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 pbened...@apache.org 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 seb...@gmail.com wrote: On 6 September 2011 05:44, David Karlsen davidkarl...@gmail.com 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 seb...@gmail.com følgende: On 6 September 2011 04:33, Henri Yandell flame...@gmail.com wrote: On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
I am going to play with surefire executions and see how that goes.
Gary
On Sep 3, 2011, at 19:37, Mark Struberg strub...@yahoo.de 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 seb...@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 flame...@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 garydgreg...@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-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 Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
On 6 September 2011 04:33, Henri Yandell flame...@gmail.com wrote: On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
I think tying to sun classes is a bad idea. Den 6. sep. 2011 05:54 skrev sebb seb...@gmail.com følgende: On 6 September 2011 04:33, Henri Yandell flame...@gmail.com wrote: On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote: On 3 September 2011 05:37, Henri Yandell flame...@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. 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
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 phil.ste...@gmail.com To: Commons Developers List dev@commons.apache.org 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 scolebou...@joda.org wrote: On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com 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
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 phil.ste...@gmail.com wrote: On 9/2/11 4:06 AM, Gary Gregory wrote: On Sep 2, 2011, at 1:21, Stephen Colebourne scolebou...@joda.org wrote: On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com 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 3 September 2011 05:37, Henri Yandell flame...@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 garydgreg...@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-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 seb...@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 flame...@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 garydgreg...@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-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 scolebou...@joda.org wrote: On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com 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 12:06, Gary Gregory garydgreg...@gmail.com wrote: On Sep 2, 2011, at 1:21, Stephen Colebourne scolebou...@joda.org wrote: On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com 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
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 garydgreg...@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-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 flame...@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 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 garydgreg...@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-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 scolebou...@joda.org wrote: On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com 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
On 2 September 2011 01:20, Gary Gregory garydgreg...@gmail.com 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
