Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 5804 invoked from network); 7 Jun 2007 16:02:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 7 Jun 2007 16:02:47 -0000 Received: (qmail 63607 invoked by uid 500); 7 Jun 2007 16:02:50 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 63581 invoked by uid 500); 7 Jun 2007 16:02:50 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 63572 invoked by uid 99); 7 Jun 2007 16:02:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jun 2007 09:02:50 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Jun 2007 09:02:46 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id EB7EF714163 for ; Thu, 7 Jun 2007 09:02:25 -0700 (PDT) Message-ID: <9700553.1181232145962.JavaMail.jira@brutus> Date: Thu, 7 Jun 2007 09:02:25 -0700 (PDT) From: "Patrick Linskey (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Commented: (OPENJPA-244) Java 2 Security enablement MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502397 ] Patrick Linskey commented on OPENJPA-244: ----------------------------------------- I think that an important design goal here is minimal invasiveness into the code. Java 2 security is something that many of us have never seen as an issue in practice, so ensuring that the security-friendly mechanisms are just as easy to use as the unfriendly versions is pretty important IMO. Additionally, I'm concerned about the extra overhead incurred by these calls, which makes me think that caching might be a good idea. Given that you demonstrate in point 2 above that it is legit to cache the return values of the security-wrapping calls, can we achieve better encapsulation? For example, why not just have a J2DoPrivHelper.getDeclaredMethod() call that does the right thing internally? > Java 2 Security enablement > -------------------------- > > Key: OPENJPA-244 > URL: https://issues.apache.org/jira/browse/OPENJPA-244 > Project: OpenJPA > Issue Type: Bug > Affects Versions: 0.9.8 > Reporter: Kevin Sutter > Attachments: J2DoPrivHelper.java > > > Via some testing with the WebSphere Application Server, it's been discovered that we're missing some doPriv blocks through out the OpenJPA code base. This JIRA report will be used to resolve these issues. More specific examples will be posted later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.