incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <andrew.jaqu...@mac.com>
Subject Re: Classmapping and final classes
Date Mon, 21 Jan 2008 19:05:37 GMT
I cannot imagine a class with more security implications than  
AuthorizationManager (or AuthenticationManager), can you? :)

The AuthManager classes were deliberately NOT built to be extended.  
The Josh Bloch rule applies here: design classes for extension, or  
else forbid it.

Here's the other thing. With something so important, I don't want to  
just take the easy way out and say, "oh yeah, just extend it." We  
can't just casually hack our way around until something works. We need  
a scenario, some use cases, a design, and a plan. "Embedding" sounds  
like the scenario, but I am just guessing. What are the use cases? The  
plan? An enhancement request in JIRA would be a good start...

Andrew

On Jan 21, 2008, at 13:21, Janne Jalkanen <Janne.Jalkanen@ecyrd.com>  
wrote:

>
> On 21 Jan 2008, at 19:49, Andrew Jaquith wrote:
>
>> The classes are final because they are not meant to be extended. We  
>> do not have any plans to change this.
>
> The classmapping mechanism is really intended for people Who Really  
> Know What They Are Doing And Don't Mind The Classes Being Broken  
> From Version To Version But Would Like To Extend The Code Without  
> Having To Re-Patch Every Version.  So when I created it, I didn't  
> look too deeply on which classes were final and which weren't.
>
>> Are you asking about this because you would like to know how to  
>> embed JSPWiki? We may need to come up with an alternative way of  
>> making this work...
>
> What is the reason to make them final?  Are there any potential  
> security issues?
>
> /Janne

Mime
View raw message