incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Jaquith <>
Subject Re: Classmapping and final classes
Date Mon, 21 Jan 2008 21:03:38 GMT
Janne- I do not want to get into a philosophical debating match over  
extensibility generally speaking. I do, however, want to you to  
understand that the two classes we are talking about, specifically,  
were not meant to be extended. That is to say, I did this 100%  
intentionally. There are other parts of the auth API that are  
specifically designed to be hacked - such as the JAAS login stack and  
the Authorizer classes. We also have, I would point out, a way of  
disabling the authorization checks *entirely*.

Do we know whether any of these methods would satisfy the need? I  
don't think we do. That is why I'm suggesting here is that we get a  
least a JIRA bug filed about embedding, or whatever the purpose of  
this is for. Is that so much to ask?

But it is a bit much to ask to just arbitrarily change a very, very  
sensitive class just because of a single email on the dev list. Let us  
not treat this matter so casually.

On Jan 21, 2008, at 15:34, Janne Jalkanen <>  

> On 21 Jan 2008, at 21:05, Andrew Jaquith wrote:
>> I cannot imagine a class with more security implications than  
>> AuthorizationManager (or AuthenticationManager), can you? :)
> Considering that extending it is possible to anyone with access to  
> source code *anyway* (they just remove the final identifiers), no, I  
> can't think of any security implications.
>> The AuthManager classes were deliberately NOT built to be extended.  
>> The Josh Bloch rule applies here: design classes for extension, or  
>> else forbid it.
> Yes, but no.   The class mapping mechanism we currently have is  
> really meant for people who hack JSPWiki anyway, but do not want to  
> apply patches to track changes in the source code all the time, as  
> even a simple reformatting might invalidate their patch.
> We don't have to really to care about design here; only public APIs  
> and public extension mechanisms.
>> 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...
> I have no idea what people are using it for, but apparently they  
> are.  And I would rather people come up with a way to do it, rather  
> than we having to make an up-front design which might not do what  
> people want.
> I mean - it's open source.   It's not us who is casually hacking  
> around the code - it's the users.  The more power they get, the  
> better.
> Having said that, I'm all for having a proper developer API and  
> correctly designed extension mechanisms, and use cases and plans and  
> roadmaps and releases and requirements management and all that jazz,  
> but to me it feels somewhat odd to say to an open source hacker that  
> "you can't extend it because we want you to extend only things that  
> we have decided to be extensible."
> /Janne

View raw message