Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of jak-struts-user@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: user@struts.apache.org
From: Laurie Harper <laurie@holoweb.net>
Subject: Re: [OT] Hiding methods
Date: Fri, 17 Feb 2006 15:18:16 -0500
Lines: 39
Message-ID: <dt5b28$8c2$2@sea.gmane.org>
References: <43F48BD7.2000809@dkfz-heidelberg.de>
    <dt2g1m$s3h$1@sea.gmane.org>
 <33170.170.201.180.136.1140114498.squirrel@webmail.chiron.lunarpages.com>
 <dt31se$o4h$2@sea.gmane.org> <43F529DC.7080301@omnytex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5 (Macintosh/20051201)
In-Reply-To: <43F529DC.7080301@omnytex.com>
Sender: news <news@sea.gmane.org>

The Java security manager infrastructure. That's what it's there for :-)

L.

Frank W. Zammetti wrote:
> What is so objectionable about it?  If you think securing a method is a 
> good idea (I'm not sure I do, but let's assume for the sake of 
> argument), why is this answer "square"? :)  I don't doubt there is a 
> better answer, but what is it?
> 
> Frank
> 
> Laurie Harper wrote:
>> Frank W. Zammetti wrote:
>>> I saw a very similar question asked a few months back in a general Java
>>> forum, and I suggested an answer that I've never had the chance to
>>> actually try out... the theory is interesting though...
>>>
>>> In the method you want to "protect", immediately throw an exception and
>>> catch it.  Then, parse the stack trace and see who the caller was.  If
>>> it's not a class you want to have access to the method, throw an
>>> IllegalAccessException.
>>>
>>> Again, it's one of those things that sounds good in your head, I have no
>>> idea if it translates to anything workable :)
>>
>> Ewwww! If you're going to reinvent the wheel, at least don't make it 
>> square ;-)
>>
>> L.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org