Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Message-ID: <29358380.1201217914286.JavaMail.jira@brutus>
Date: Thu, 24 Jan 2008 15:38:34 -0800 (PST)
From: "Andrew Jaquith (JIRA)" <jira@apache.org>
To: jspwiki-dev@incubator.apache.org
Subject: [jira] Commented: (JSPWIKI-155) Allow customisation of core classes
 via ClassUtil.getMappedObject
In-Reply-To: <26708289.1201185218240.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JSPWIKI-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562301#action_12562301 ] 

Andrew Jaquith commented on JSPWIKI-155:
----------------------------------------

At the risk of crawling out on the branch farther than I'd like with respect to AOP, I think calling the ClassUtils functions "lightweight AOP" isn't quite accurate. AOP, as far as I understand, typically involves addition of functions via bytecode injection. That's a build-time modification.

That's not what we're doing here. Rather, it's simple arbitrary substitution of one class with another at RUN-TIME. That makes the whole system much easier to subvert.  And indeed, you've sketched out the subversion model rather well: "put in a class in a JAR file and prefix it with 'a_' or something", then, simply twiddle ini/classmappings.xml].

So, now that we have something that is "already fundamentally broken," we want to break it more? It boggles the mind.

Allow me to quote liberally from Wikipedia:

"The potential of AOP for creating Malware should also be considered. If security is a cross cutting concern implemented through the application of AOP techniques, then it is equally possible that breaking security can be implemented through injecting additional code at an appropriate place. For example, consider the impact of injecting code to return true at the beginning of a password verification function that returns a boolean value. This means that all programmers using languages that can be subjected to AOP techniques need to be aware of the potential of AOP to compromise their systems." (http://en.wikipedia.org/wiki/Aspect-oriented_programming)

I'm not usually such a prima donna about stuff like this. If I'd been paying attention to this feature during the 2.5 development cycle, I would've raised the flag much earlier. 

Heck, if we want "aspects," let's just require AspectJ in the toolchain. Or the intrepid developers who need to extend/modify core classes can simply do what everyone else does: keep their own local, patched build.

> Allow customisation of core classes via ClassUtil.getMappedObject
> -----------------------------------------------------------------
>
>                 Key: JSPWIKI-155
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-155
>             Project: JSPWiki
>          Issue Type: Improvement
>          Components: Core & storage
>    Affects Versions: 2.6.0
>            Reporter: Simon Kitching
>            Priority: Minor
>
> The WikiEngine class uses the ClassUtils.getMappedObject method to locate its critical helper objects, rather than just call "new".
> The intentention of this existing code is for people to be able to override the core implementations with custom ones - with the warning that these core objects do not have stable public apis, and may change in any release. Unfortunately because (a) the returned object is cast to a concrete type, and (b) many of these concrete types are declared "final" this facility is actually almost useless.
> It would be nice for the "final" to be removed from these classes, and from their member methods so that getMappedObject becomes useful. Alternately, interfaces could be created for the concrete classes that WikiEngine currently uses, and all code modified to use the interface instead; the existing implementations could then remain final. That approach is much more intrusive though.
> Note that in discussions on the email lists it has been suggested that the "final" qualifier on these classes helps make jspwiki more secure. Personally I'm not at all convinced that is true though.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.