Version 4

    This page is currently a work-in-progress (see MODE-497) and documents the way in which the ModeShape code should use the Java security checks (e.g., AccessController.doPrivileged calls) to verify it calls only accessible, privileged code.


    For details, see Security Coding Guidelines for the Java Programming Language Version 3.0 for more detail about these security checks.


    ModeShape has the notion of extensions, where developers can extend the functionality of the system by writing custom components. Right now, extensions take the form of sequencers, connectors, mime type detectors, class loader factories, and security contexts. All but the last two of these components are loaded reflectively, cast to ModeShape-defined interfaces, and used within the JcrConfiguration. Class loader factories and security context are not loaded reflectively, but are instantiated by applications and passed by reference into ModeShape.


    ModeShape has two simple frameworks that do most (all?) of the heavy lifting of using reflection. The Reflection class encapsulates the Java reflection API to make it easier and simpler to use. The ComponentLibrary framework instantiates and manages as set of "component" instances using the Reflection utility class, and is used by the MimeTypeDectectors and extended by the SequencerLibrary. The RepositoryService uses Reflection to manage the set of RepositorySource instances.


    Update:  10 June 2011


    As per the discussion on IRC, all the Method#invoke also need to be wrapped in the doPrivileged block - Please see the commit on the branch here.


    Verified that all the tests pass when mvn clean install -Pintegration is executed.


    Update:  9 June 2011


    Thread.currentThread().getContextClassLoader(), System.getProperty() and System.setProperty() have been wrapped in doPrivileged method - Please see the commit on branch here.


    All the tests pass after these changes.


    For the reflection based invocations, here's the list where the code is used, probably these should be wrapped after a simple audit of the code whether wrapping is needed or not. Here's the list of occurrences (linked to the appropriate line in github source code).