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
